夜雨聆风过去一年，很多开发者对 AI 编程的感受都变了。
一开始，我们惊讶于它能补全代码、解释报错、写脚本。后来，我们开始让它改组件、补测试、做重构。再往后，Claude Code、Codex 这类工具出现以后，AI 已经不只是坐在编辑器旁边给建议，而是能进入代码库，读文件、改文件、跑命令，提交一整组变更。
这当然让人兴奋。但真正用久以后，兴奋感会慢慢变成另一个问题：AI 现在确实能写代码，而且写得很快。可是，围绕代码的一切怎么办？
它会不会推错分支？会不会绕过测试？会不会改出一个看起来能跑、但其实破坏架构边界的方案？会不会今天修了一个 bug，三周后又用另一种方式把同类 bug 写回来？会不会在一个大 diff 里顺手做了十个“贴心优化”，让你根本不知道该从哪里 review？
Mikko Tikkanen 在《My Agentic Development Workflow》里讲的，正是这个问题。
这篇文章表面是在介绍他的 AI 开发工作流，工具包括 Claude Code、OpenAI Codex、Wispr Flow、Sentry、Vercel、GitHub CLI 等。但如果只看工具名，就看浅了。
它真正想表达的是：当 AI 写代码越来越便宜，真正昂贵的东西变成了信任。
代码本身不再是最大的瓶颈。真正的瓶颈变成了：我们如何知道这些代码是对的，如何让 AI 不断减少重复错误，如何让一次开发的经验沉淀成下一次开发的优势。
换句话说，AI 时代真正要工程化的，不只是业务代码，而是“AI 参与开发的整个流程”。
模型会变强，但流程不会自动变好
作者开头有一个判断很重要：模型会持续进步，但流程不会自己进步。
今天的模型比半年前强，半年后的模型大概率又会更强。我们不用做太多事情，模型厂商就会替我们提升推理能力、代码能力、上下文能力和工具调用能力。
但项目流程不会自动变好。
如果测试本来就慢，AI 只会更快地撞上慢测试。如果分支保护本来就弱，AI 只会更快地把错误推到 main。如果代码库没有清晰约定，AI 只会更快地产生第二套、第三套“也能工作”的实现方式。如果团队没有记录决策，AI 每次都会重新猜一次历史原因。
这就是作者真正关注工作流的原因。
他不是在说“我有一套很酷的 AI 工具组合”。他是在说：工具会变，模型会变，但你要有一套能吸收错误、减少混乱、积累上下文的开发系统。
如果只是让 AI 帮你写一次代码，你需要的是提示词。如果你想长期把 AI 放进真实工程里，你需要的是流程。
AI 不是替代经验，而是放大经验
文章里还有一句很容易被忽略的话：这些工具不能替代你知道自己在做什么的经验，它只是让你用已有能力做更多事情。
这句话很不讨喜，但很真实。
AI 编程经常被包装成“人人都能做软件”的故事。对小工具、原型、一次性脚本来说，这个说法有一定道理。但到了长期维护的系统，尤其是多人协作、有线上用户、有历史债务、有隐含业务规则的代码库里，问题就不一样了。
AI 能很快生成代码，但它不天然知道什么是合适的边界。它能补一堆测试，但不一定知道哪些行为最值得保护。它能看起来很自信地解释方案，但不一定理解这个项目过去为什么没有这么做。
所以，AI 放大的不是“凭空产生的工程能力”，而是你已经具备的判断力。
强开发者用 AI，会把规格、边界、验证、复盘做得更快。弱开发者用 AI，可能只是更快地产生自己看不懂的复杂度。
这也是为什么作者反复强调流程。流程的作用不是让人消失，而是让人的判断力进入系统，变成 AI 每次都要经过的轨道。
核心循环：先想清楚，再让 AI 动手
作者提到的主流程叫 Compound Engineering。它的循环是：
brainstorm → plan → work → review → compound
brainstorm 是先讨论方案、需求和边界，不急着写代码。plan 是基于现有代码模式和上下文文件，把实现拆成可执行步骤。work 是真正写代码、跑测试、修问题。review 是对照已知 bug、项目约定和变更目标做检查。
最关键的是最后一步：compound。
很多人做完一个任务，停在“代码能跑，测试通过，提交了”。作者不是。他会把这次任务中学到的东西沉淀下来：哪些地方让 AI 困惑，哪些 bug 值得记录，哪些规则应该写进 AGENTS.md，哪些测试应该补上。
这一步才是整篇文章的灵魂。
它意味着每个任务不只是为了完成当下需求，还要让未来的任务更容易。
如果 AI 总是在同一个地方犯错，那不只是 AI 的问题，也可能是指令、文档、测试或代码结构没有把这个坑暴露出来。下一步不是继续骂模型，而是把这个错误转化成规则、测试、检查或文档。
这就是 compound 的意思：让经验复利。
上下文文件是团队给 AI 的长期记忆
作者提到，AGENTS.md、bug logs、decision records 这类文件会随着每个 feature 增长。Agent 会变好，不只是因为模型变强，也因为它所处的上下文变丰富了。
很多人理解上下文，还是停留在“这次对话里多贴一点代码”。但对真实工程来说，更关键的是稳定上下文：项目怎么启动，哪些目录不能碰，什么命令代表验证完成，过去踩过什么坑，某个设计为什么这样做。
这些东西如果只存在人的脑子里，AI 每次都要猜。如果只存在聊天记录里，下一次会话可能就丢了。如果沉淀到代码库里的文档、规则、测试和脚本中，它就变成了系统的一部分。
所以 AGENTS.md 不是装饰文件，也不是提示词备忘录。它更像是给 AI 的工程入职手册。
但作者的思路还更进一步：这个手册不是一次写完，而是随着错误持续更新。每次 AI 犯错，都是一次改进上下文系统的机会。
测试是 AI 工作流里最可靠的记忆
文章中最值得借鉴的一点，是作者把测试称为最重要的反馈环之一。
原因很简单：测试不会忘。
AI 会忘。上下文会溢出。会话会重启。模型会换。人也会忘记三个月前为什么加了一个边界判断。
但测试不会忘。
当你把一个预期写进测试里，它会在今天、下周、半年后继续提醒所有修改者：这个行为不能坏。对 AI 来说，这尤其重要。因为 AI 写代码快，跑偏也快。如果没有足够明确的测试反馈，它会在错误方向上跑得更远。
作者偏好在开发过程中使用单元测试，因为反馈快。一个几秒钟能跑完的测试套件，可以让 Agent 写、测、修、再测，形成短循环。等大块工作完成后，再跑端到端测试。只有这些检查都通过，才进入提交。
这背后的原则是：提示词是软约束，测试是硬反馈。
你告诉 AI “不要破坏这个逻辑”，它可能听懂，也可能忘。你写一个测试，它每次都会执行。
在 AI 编程时代，测试不是变得不重要了，而是更重要了。因为代码生产速度越快，验证系统就越需要跟上。
不要相信 AI 会永远听话，要设计它不能轻易越界的结构
作者提到一个很现实的问题：有些 Agent 并不会一直遵守指令。比如你告诉它不要直接 push main，它还是可能这么做。
这不是小问题。
很多人构建 AI 工作流时，习惯把希望放在提示词上：告诉它不要这么做，告诉它一定要那样做。但真实系统里，不能把安全寄托在“它应该会听懂”上。
可靠的做法是结构性约束。
比如用 GitHub branch rules 锁住主分支，用 pre-commit hook 阻止危险操作，用 CI 要求测试通过，用 PR 流程让变更先进入 review。
这和“短牵绳”方法其实是同一种精神，只是层次更高。
短牵绳强调人在每一步看 diff，不让 AI 一路狂奔。作者这篇文章强调的是：除了人看，还要把代码库和工具链设计成 AI 不容易越界。
人会累，提示词会被忽略，但结构性约束会一直在那里。
自动化 review 不是替代人，而是处理人看不过来的部分
AI 生成代码以后，review 压力会明显变大。
过去一个人一天写几百行代码，review 还勉强跟得上。现在 AI 可以在很短时间里改十几个文件，生成一堆测试和辅助逻辑。人不可能把所有内容都按传统节奏逐行看完。
所以作者使用自动化 review，而且尽量在本地先跑，避免每次都把成本推到 GitHub review 工具和 CI 上。
这不是说人不 review 了。相反，是为了让人的 review 更集中。
自动化检查负责提前拦截常见问题：类型错误、测试失败、明显代码味道、安全扫描、项目约定违反。人则负责判断更高层的问题：这个方案是否符合业务目标，是否放在正确层级，是否引入了不必要复杂度。
AI review 像一个更聪明的 linter，但不是最终责任人。最终责任仍然在人这里。
安全和生产监控让闭环变完整
作者没有把流程停在“PR 合并”。
他还提到安全红队和生产监控。安全问题往往不是普通 code review 能完全发现的，所以他会让 Agent 按攻击模式去测试服务，再对照实现寻找风险。上线以后，即使测试和 review 都过了，也仍然会有真实用户、真实数据、真实规模带来的问题，所以日志、监控和请求上下文会成为下一次修复的输入。
这让整个工作流形成闭环。
需求进入系统，AI 参与实现，测试给出快速反馈，review 做质量判断，分支和 CI 控制合并，生产监控捕捉真实问题，事故再回到文档、测试、规则和下一轮开发。
这已经不是“让 AI 写代码”了。这是在搭一个会学习的工程系统。
这篇文章真正值得学什么
如果只学工具，很快会过时。今天是 Claude Code 和 Codex，明天可能是别的模型。今天是某个 review 工具，明天可能被 IDE 内置能力替代。
但这篇文章背后的思想不会过时。
它真正值得学的是几个判断。
代码生产正在变便宜，但可信代码仍然昂贵。
AI 的输出越快，验证、review、分支保护、监控和知识沉淀就越重要。
每次 AI 犯错，都不应该只停留在“这次修掉”，而应该追问：能不能把这个错误变成测试？能不能写进 AGENTS.md？能不能增加一个检查？能不能留下一个决策记录？
开发者的角色也在变化。过去我们主要是代码作者。现在我们越来越像开发系统的设计者：定义目标，拆解任务，安排反馈环，设置护栏，判断结果，沉淀经验。
未来厉害的开发者，不一定是最会让 AI 写出一大段代码的人，而是最会设计 AI 工作闭环的人。
这也是我读完这篇文章最大的收获：
AI 时代，真正的工程能力不是把代码写得更快，而是让更快产生的代码仍然可以被信任。
当你能做到这一点，AI 才不是一个会制造混乱的高速打字机，而是被纳入工程体系的一部分。
它写代码，你设计系统。
它执行任务，你负责判断。
它带来速度，你负责让速度沉淀成质量。
这才是 Agentic Development Workflow 真正想讲的东西。
参考资料：
- Mikko Tikkanen, My Agentic Development Workflow: https://www.fixerofthenorth.com/blog/my-current-agentic-development-workflow
#AI #智能体 #工程实践
