如何给不同类型的软件制定 AI Workflow
不同类型的软件，适合的 AI Workflow 是不一样的，我大致把它们分成两类：内容型的和功能型的。
#AI Coding
共 46 篇文章。
构建远程AI工作流
中秋出去旅游前，我已经预设了一些任务，准备在旅途中远程连接家里的电脑，让 AI 继续做开发。电脑放在家里也是闲着，想着任务提前安排好，出去玩的时候偶尔看一下进度就行。
如何选择模型与推理强度
最近在做可视化 Agent，涉及大量开发任务和测试，Token 完全不够用。目前自己买了每月 200 美元的 ChatGPT 套餐，有一个没有周额度限制的 GLM 老套餐，还买了 OpenCode Go，但感觉仍然不够用。尤其是 GPT，虽然已经买到 200 美元，额度还是经不起这样消耗。
如何最大化利用你的Token
我感觉 AI 现在对我来说，就是一个游戏机，Token 就是游戏币，每天玩得不亦乐乎。只要有一个想法，立刻就能去验证和实现，这种正反馈太强了。
如何正确使用 GPT 模型的推理强度
目前我每个月买的是 200 美元的 ChatGPT Pro 套餐，在 Codex 里两三天就把一周额度消耗得差不多了，根本不够用，因此这个使用强度下，除了关注哪个模型更强，还得考虑另一个问题：我目前的使用方式对不对？同一个模型，每次任务到底应该给它多少推理预算？
从 Demo 到生产：AI Agent 工程真正难在哪里
答辩里介绍了不少 AI 与数据可视化结合的实践。有些能力已经能够稳定生成内容，也开始进入实际使用阶段。
AI 时代到底应该学什么
今年的热点已经换了好几茬。年初还在聊 Harness，年中变成 Loop Engineering，现在又开始讲 Graph Engineering。名字一个接一个，每个都说自己代表下一代工作方式。
AI协作生成PPT的难点-需求澄清
这次案例本身也整理成了一个可以直接阅读的网页：<a href="https://t.zhouchangju.com/english/toefl-study/" target="blank" rel="noopener noreferrer">TOEFL 学习复盘网页</a>。
读《State of Open Source AI 2026》：模型会越来越便宜，真正应该掌握的是Harness
今天看到 Mozilla 发布的 《The State of Open Source AI 2026》。一开始我以为这又是一份讨论开放模型和闭源模型谁更强的报告，但完整看下来以后，发现它真正想讨论的并不是模型排名。
如何把公司文档里的经验，变成自己项目里的工程约束
之前我调研过一个同类的二次开发项目。一开始我的想法很直接：把它的源码和文档找出来，看看他们怎么做的，哪些架构可以照着用，哪些功能可以直接参考。
让AI自主开发跑起来：先写验收，再拆任务
最近我在尝试把一批开发需求交给多个 AI 执行。这批需求的一部分来自会议录音转写：里面有产品边界、技术方案、人员分工，也有口误、同音字和讨论到一半又被推翻的想法。最直接的做法是把转写总结成任务列表喂给 AI，等它写完再补测试和自测。
从会用 AI 到建设自己的 AI 基建
过去一年，很多人对 AI coding 的理解还停留在“让 AI 帮我写代码”。但真正拉开差距的地方，可能已经不在于一次提示词写得多漂亮，而在于你能不能把反复发生的工作、隐性的判断经验、验证规则、学习循环攒成可复用的 AI 基建。
OpenCode学习笔记
这篇先作为 OpenCode 的长期学习笔记，不急着写成完整教程。后面关于 OpenCode 的配置、踩坑、Agent 设计、Skill 复用，都放在这里。
评测驱动的刻意练习
最近在复盘 AI Coding 的 Prompt 质量，过程中发现一个问题：我一开始很容易把结论推得太满。
解读 Codex-maxxing for long-running work
最近看了一份 OpenAI 的白皮书，标题是 Codex-maxxing for long-running work。一开始我以为它会讲很多具体技巧，比如怎么写 prompt、怎么开线程、怎么安排自动化。但读完之后发现，它真正想讲的不是某个功能，而是一个更大的变化：
Loop Engineering
前阵子在 Ziron 里跑服务端 packet 切片迁移，我把整个流程拆成了一个可以自己循环的系统：每一轮提取一个 packet 组，写 fixture、跑兼容性测试、更新文档、提交、合并，然后读 STATUS.md 里写好的下一个任务，继续下一轮。这就是后来被叫做 Loop Engineering
如何设计项目AI改造Skill
最近在 AgentInfra 里做了一个新的 Skill，名字叫 harness-builder。
PI学习笔记
DeepSeek V4 系列支持 Thinking / Non-Thinking 双模式，thinking 默认 enabled。关闭方式：
TTS工具开发笔记
这次本来只是想解决一个很小的问题：给托福听力弱词生成一批质量还可以的音频材料。
Agent技术选型分析
Agent 框架选型不能只看谁最火。真正要先问的是：流程有没有分支和重试，任务会不会跑很久，状态要不要恢复，工具和人类审批是不是链路的一部分。
从harness看未来软件工程师的工作职责
我现在更确定的一点是：AI 写得快，不等于系统交付得快。工程师的价值不会只剩“亲手敲代码”，但也不会自动消失，它会更多落在问题定义、执行环境、反馈回路和结果验证上。
weekly-summary-20260125
这个想法部分正确。但随着时间的推移，我越来越意识到，真正成功的工程师不一定是最优秀的程序员，而是懂得驾驭代码之外一切的人。
Prompt-ScrollTelling
网页内容： 1、滚动叙事网页内的文案 2、滚动叙事网页内的图像 3、文案和画面风格、交互参考纽约时报或南华早报网站中叙事可视化内容
weekly-summary-20260111
这在经济学上称为"不对称收益"（asymmetric returns），就是风险和收益不对称。失败的可能性很大，但只会损失一小笔钱，成功的可能性很小，但是一旦成功，就会获得巨大收益，简单说就是"小亏大赚"。
2025年SeeConf参会记录
5 年前，偏右在做 Ant Design，现在他在探索 AI 工程和前端的职责边界。他将在 SEE Conf 2025 分享《AI for Frontend》。
weekly-summary-20251019
假设你要重构一个大型项目的代码： 1. 1. 第一步：让 Sonnet 4.5 分析整个项目架构，找出问题点，制定重构方案 2. 2. 第二步：让多个 Haiku 4.5 实例并行处理各个模块的具体重构 3. 3. 第三步：再让 Sonnet 4.5 做代码审查 这样一来，复杂的部分由最强的模型把关
架构驱动的软件方法论演进轨迹
在软件工程的早期发展阶段，开发过程主要遵循传统的软件开发生命周期（SDLC）模型，如瀑布模型。这些模型通常将设计视为编码之前的一个单一、宏大的阶段 。在这种线性思维下，软件开发被视为一个从需求到设计再到实现的顺序过程。然而，随着软件系统的规模和复杂性呈指数级增长，这种方法的局限性日益凸显。实践表明，
AI Coding-2025年8月
用 AI 写代码以后，我最大的感受不是“终于不用学习了”，而是更容易误以为自己已经掌握了。代码能跑出来，只说明模型完成了一次生成；需求有没有讲清楚、边界有没有守住、改动能不能验证，还是人的责任。
AI时代架构师的核心职责
AI 的普及并未削弱架构师的价值，反而要求其从 "代码编写者" 转向 "全局掌控者"，核心职责主要体现在需求与架构的翻译、质量与效率的守护、团队协作的枢纽这几个方面。
AI开发中是否应该使用框架
在 B 站看到一个视频：不要用 AI 框架，作者的观点和观众的评论很有意思，因此我用 AI 将其整理了一下。
文档驱动开发
文档驱动开发的核心思想是：No Code - 先用 AI 生成完整的技术文档，再基于文档生成代码。这种方法论源于我在实际项目中的探索和思考。
资讯可视化流程分析
这篇想解决的是一个很具体的阅读问题：用户读资讯时，遇到数字、公司、术语和事件线索，经常要跳出去查。我的方案不是另做一个大而全的 Agent，而是把文章拆成可追踪的 chunk，再把解释、图表和时间线嵌回原文附近。
近期关于AI Coding的感想
最近这段时间，我几乎每天都在和各种 AI 编程工具打交道。这个过程有点像是在玩一场大型的"抽卡游戏"，有时候你会抽到 SSR，有时候则是连续的 R 卡。
近期的学习和工作流
这段时间最大的收获是形成了「早上听 -> DeepResearch 调研 -> 生成可视化网页巩固理解」这条信息获取闭环，以及用多窗口并行写代码来压榨 AI Coding 的效率。代价是同时处理太多线索容易被【打断】后失忆，所以提前一天梳理第二天的工作、保持单一时间线，比单纯堆窗口更重要。
Chrome插件开发技术选型
在过去的几周里，我和我的团队深度参与了一个 Chrome 插件开发项目，从最初的技术选型到最终的 POC 验证，踩了不少坑，也积累了一些经验。今天我想把这些经验分享给正在考虑 Chrome 插件开发的你。
技术拆解-CozeStudio
Coze Studio 最值得看的不是“低代码 Agent 平台”这个标签，而是它怎么把模型、工作流、插件、知识库、数据库和发布管理放到一个工程系统里。它的问题也很典型：Agent 产品一旦从 demo 走向平台，就不只是 prompt 和工具调用，而是领域模型、资源管理、运行时、权限和运维一起上桌
Gemini CLI 使用技巧
这篇是我用 Gemini CLI 一段时间之后攒下的技巧和踩坑记录。不是文档搬运——官方文档能查到的我就不重复了——重点是那些实际用起来才发现的点：什么场景它好用、什么场景它会让你抓狂、以及跟 Claude Code 比起来各自的定位。
Vibe Coding Experience Summary
Recently, in my development work, I have extensively used Vibe Coding, continuously engaging in a demand-feedback-correction cycle with AI IDEs. Durin
Vibe Coding经验总结
最近在开发工作中，我大量使用了 Vibe Coding，不断与 AI IDE 进行需求-反馈-修正的循环交互。在这个过程中，我一直在思考如何能够将 Vibe Coding 的效果发挥到最大。我认为最关键的是需要整理出一套方法论，解决以下两个核心问题：
Gemini CLI 源码分析
不过目前使用起来，感觉还不达成熟。不过因为是开源的，估计过一段时间会好很多，可以当成一个储备的工具先关注着。 目前的重点，还是借助其源码，学习一下AI CLI的实现思路。
可视化图表生成MCP
这篇不是在讨论“再做一个图表生成器”，而是在记录一件更实际的事：已有图表能力怎么变成 AI 可以稳定调用的工具。我的判断是，先把成熟 case、schema 和渲染出口整理好，比从零开始训练一个“会画图”的模型更靠谱。
weekly-summary-20250406
灵活适配的模型选择 得益于多 Agent 架构，我们可以根据任务的复杂度和模型的特点，灵活选择最适合的模型。例如，对于数据拆分这类相对简单的任务，7B 小模型即可快速输出结果，确保高效执行；而对于更复杂的任务，则可以选择更强大的模型来保证输出质量。
2025年D2参会感想
所有工作能够集中在一个IDE内部完成，而不需要跳转到其他地方时，效率会大大提高。例如，之前使用AI工具时，我们通常需要在ChatGPT中对话，然后将返回的结果复制粘贴到其他地方进行后续处理。这种操作方式不可避免地会导致思维被打断，专注力也因此被分散。 相比之下，如果所有工作都能在同一个IDE中完成，
LLM开发经验
LLM 适合做的两种事情：抉择+多样性(比如：生成搞笑的风格)。
AI浪潮下开发模式的变革
AI 浪潮正在改变软件开发模式，为开发者带来新的机遇和挑战。本文通过实际工作案例讲述了 AI 对个人开发工作的影响，以及 AI 时代下产品开发模式的变革，并分析了大模型时代程序员与 AI 工具的定位，希望能帮助开发人员提前布局，抓住新一轮发展机遇。
动态折线图开发问题汇总
最近在给业务方开发动态折线图，期间遇到N多问题，这里做个记录，就当是技术复盘了，避免下次重复踩坑。