AI编程实战指南：从传统编码到 AI 协作

过去半年里，我个人构建并交付的几个项目，从需求梳理、实现、测试、部署，到后续线上问题的修复和重构，绝大部分具体编码工作都交给了 AI 来完成。

这里面既有业务项目，也有内部工具。经历过的事情也不只是“写一个页面”这么简单，而是完整走过了需求变更、接口对接、测试、部署、故障、回滚、继续迭代的整个链路。真正做下来之后，我越来越明确一件事：AI 编程带来的最大变化，不是“代码生成速度更快”，而是工程师的工作重心正在发生转移。

很多以前必须亲自下场逐行敲的事情，现在可以交给 Agent；但与此同时，需求拆解、上下文组织、流程约束、结果验证，反而变得比以前更重要。你不再只是在写代码，你在设计一套让 AI 持续稳定工作的工程系统。

这篇文章不是想证明“人已经不需要写代码”，也不是想把 AI 描述成无所不能的黑盒。它更像是一份阶段性实战总结：当 AI 真的进入日常开发流程之后，工程师应该如何重新组织自己的工作方式，哪些地方值得投入，哪些地方最容易踩坑。

重新定义工程师的角色

最开始我以为，AI 编程的核心是“提示词写得够不够好”。后来发现这只是表象。

真正影响产出的，往往不是一句提示词本身，而是你有没有把事情想清楚：

需求有没有拆到足够明确
约束和边界有没有写清楚
项目的结构和规则有没有让 Agent 看得懂
交付前有没有完整的验证闭环

所以工程师的核心工作，正在从“直接实现功能”转向“设计任务系统”。

过去我们最关注的是：这段代码怎么写、这个接口怎么调、这个 bug 怎么修。现在更常见的问题变成了：

这个任务应该怎么拆
哪些约束必须前置
需要给 Agent 哪些上下文
哪些信息应该让 Agent 自动获取，而不是靠聊天补充
需要哪些工具和流程来兜底

这也是为什么很多人会有一种错觉：刚开始用 AI 的时候感觉非常惊艳，但任务一复杂就开始失控。不是模型突然不行了，而是工程问题并没有消失，只是从“实现问题”变成了“组织问题”。

换句话说，工程师越来越像一个系统设计者。代码依然重要，但它不再是唯一的主战场。你需要设计的是一整套“让 AI 不容易跑偏”的环境。上下文怎么组织、文档怎么放、流程什么时候触发、结果怎么验证，这些决定了 AI 最终能不能稳定交付。

用 Agent 审查 Agent

当 AI 开始大量产出代码后，新的瓶颈很快就出现了：人工 review 跟不上了。

以前团队一天的代码增量相对可控，人工看 diff 还勉强能扛住。现在如果 Agent 一次能生成几个文件、几十个函数、连带测试和文档一起改，人工 review 的压力会突然变得很大。不是说人不能 review，而是人的注意力是稀缺资源，不可能无限放大。

所以我后来做了一套自动 review 流程，让 Agent 在提交前先做第一轮检查，再由另一个 Agent 做交叉审查。人依然保留最终决定权，但不再承担所有初筛工作。

这件事的价值不只是“省时间”，更重要的是让 review 从“靠注意力硬扛”变成“可以规模化运行的流程”。一些人工容易漏掉的问题，比如边界分支、异常路径、命名和逻辑一致性，在 Agent review 里反而更容易被提前暴露出来。

当然，这里有一个很重要的边界：我从来不把 Agent review 当成“替代人工 review”的理由。它更像一层质量前置过滤器。能先用机器筛掉的，就不要把所有问题都留给人最后集中承担。

如果代码是 Agent 写的，那么 review 也应该尽可能让 Agent 先承担第一轮。这不是替代人工，而是把人工注意力留给更关键的判断，比如业务逻辑是否正确、架构方向是否合理、是否引入了长期技术债。

让应用对 Agent 可读

当代码生成的瓶颈下降之后，另一个更真实的问题会冒出来：验证。

很多团队以为 AI 编程的难点在“写”，其实真正难的是“确认它写得对”。如果应用的运行结果、日志、监控指标、错误信息都只能靠人肉去看，那么最后整个链路还是会卡在人工 QA 上。

所以我后来特别关注的一件事，是让应用对 Agent 可读。

这里的“可读”不是指把页面渲染给模型看一眼，而是让 Agent 能够系统地读取和理解应用运行后的反馈，例如：

UI 状态有没有变化
控制台有没有报错
接口返回是不是符合预期
日志里有没有异常堆栈
关键指标有没有出现明显异常

一旦这些信息可以被 Agent 稳定获取，验证环节就会从“人盯着页面点点点”升级成“Agent 可以独立做一轮自测和排查”。这不意味着它一定能替代所有测试，而是意味着很多重复性验证工作终于有了自动化的基础。

很多时候，真正限制 AI 的并不是“不会写代码”，而是“写完之后看不见后果”。所以让代码对 AI 可写，只解决了一半问题；让应用对 AI 可读，才有机会把开发、验证和排障连起来。

AGENTS.md 是目录，不是说明书

上下文管理，是 AI 编程从“能用”走向“好用”的关键。

我们最早踩过一个很典型的坑：试图把所有规则都塞进一个巨大的 AGENTS.md 里。结果很快发现，这种做法在项目稍微复杂一点之后几乎一定会失效。

原因很简单：

上下文窗口是稀缺资源，大文件会挤占真正重要的信息
什么都写进去，等于什么都没有重点
大而全的规则文件腐烂得极快，维护成本非常高
单个巨型文件很难做新鲜度检查、所有权管理和自动化校验

它的问题并不只是“太长”，而是它会让团队产生一种错觉：好像只要把所有东西都写进去，Agent 就自然会变聪明。但真实情况恰恰相反。信息越堆越多之后，Agent 往往只是在做局部模式匹配，而不是理解系统结构。

后来我们换了做法：把 AGENTS.md 当成目录，而不是说明书。

它只做三件事：

告诉 Agent 这个仓库的大体结构
指出核心入口和关键规范的位置
引导 Agent 去读真正应该维护在 docs/ 和代码仓库里的内容

这样做的好处很直接。第一，AGENTS.md 本身可以保持精简，不会长期腐烂。第二，真正的知识能够各归其位，由最接近业务的人维护。第三，Agent 获得的是一张地图，而不是一团糊在一起的规则文本。

给 Agent 的应该是一张地图，而不是一本 1000 页的手册。真正长期有效的知识，应该沉淀在规范文档、设计文档、接口文档和代码本身，而不是指望一个总入口文件包打天下。

为什么 AI 需要工具链，而不只是提示词

很多人刚开始使用 AI 编程时，最自然的方式是“靠提示词”。这在个人、小任务、短链路场景里完全没问题。

但只要任务开始变复杂，或者进入团队协作阶段，单靠提示词很快就会遇到天花板。

原因在于，提示词本质上是一次性的，而工程需要的是可复用、可协作、可治理的能力。你今天在一个对话里说清楚了，不代表明天另一个人、另一个仓库、另一个 Agent 还能复现同样的质量。

我后来越来越确定一件事：如果想让 AI 真正参与团队开发，就必须把能力从“个人临场发挥”升级成“团队工具链”。

一个成熟的工具链，至少要解决这几件事：

让 Agent 能连接外部系统，而不是只看当前对话
让团队约束可以被重复执行，而不是靠口头提醒
让高频流程自动触发，而不是每次手工操作
让有效的方法论能够被沉淀、复用和分发

也正因为如此，我后来越来越少把注意力放在“怎么写一个更长的提示词”上，而是把重点放在“怎么把能力组织起来”。提示词依然重要，但它更像临场指挥；真正决定上限的，是底层有没有一套能复用的基础设施。

从 Plugin 到 Marketplace：把团队能力做成可复用资产

为了让这些能力真正进入团队协作，我更习惯从 Plugin 的视角去理解整个体系。

可以把 Plugin 看成一个打包单元：它不是某一个工具，而是把连接能力、约束、自动化和方法论组合成一个可安装、可升级、可审查的团队能力包。

从这个角度看，一个完整的 Plugin 往往包含四层：

MCP：解决连接问题，让 Agent 能读系统、读文档、读环境
Rules：解决约束问题，让团队规范可以被统一执行
Hooks：解决触发问题，让流程在合适的时机自动发生
Skill：解决方法问题，把“应该怎么做”沉淀成可复用流程

这四层里，我觉得最关键的是 MCP 和 Skill。

MCP 决定了 Agent 能不能接触真实世界。没有连接，Agent 只能停留在“聊天式开发”。它写出来的东西再像样，也容易脱离真实上下文。

Skill 决定了 Agent 知不知道该怎么做。只有连接，没有方法，Agent 还是只能停留在“工具会用，但流程不稳”的状态。它知道哪里有文档、哪里有任务、哪里有日志，但并不知道拿到这些信息之后应该按什么顺序行动。

Rules 和 Hooks 的作用也很重要。前者负责把约束固化下来，后者负责把这些能力嵌入实际工作流。没有约束，团队风格会漂；没有触发，很多好流程最后还是落回“知道但做不到”。

再往上走一步，就是 Marketplace。

如果说 Plugin 解决的是“把能力打包好”，那 Marketplace 解决的就是“把能力发出去”。它的意义不是再引入一个新概念，而是让团队已经沉淀好的能力能够被规模化安装、复用和治理。只有到了这一步，AI 工具链才不再是某几个熟练用户的私人工具箱，而是能真正进入组织能力层面。

案例：用开源 Skill 框架承载工程方法

除了自己沉淀一些项目内能力之外，我也长期在用开源 Skill 框架来承载工程方法。Superpowers 是一个很典型的例子。它在 GitHub 社区有较高关注度，也已经沉淀出比较完整的 Skill 体系。

我喜欢它的原因，不是因为 Skill 数量多，而是因为它把很多“好工程实践”从口头建议变成了明确流程。

比如这些环节：

在动手前先把需求和设计想清楚
把设计拆成可执行的小任务
在隔离环境里推进实现，降低污染主工作区的风险
写完以后必须做验证，而不是口头宣布“完成了”
在适合并行的场景里，用多个 Agent 分工推进

这些事情以前也不是不能做，只是做得很依赖个人自觉。经验足够的工程师知道该这么干，但一忙起来或者团队规模一扩大，流程就很容易退化。Skill 框架的价值就在这里：它让这些行为从“建议”变成“默认动作”。

这类框架真正有价值的地方，不是“提供了多少招式”，而是帮你把团队原本依赖经验和自觉的工程习惯，变成一个能稳定复用的系统。

它也提醒了我一件事：AI 工具本身很容易被过度神化，但真正拉开差距的往往不是模型，而是你有没有把工作方法沉淀下来。模型可以越来越强，但如果方法论还是全靠临场发挥，那么质量最终还是会漂。

一个完整的 AI 开发闭环

如果把上面的能力串起来，我现在更习惯把 AI 开发理解成一个完整闭环，而不是一个单点提效工具。

一个比较稳定的流程通常是这样的：

先想清楚问题，明确目标、约束和边界
把任务拆成更小的执行单元
让 Agent 在隔离环境里完成实现
接入文档、任务、日志或接口等外部上下文
用测试、review、日志和运行结果做验证
最后再决定合并、发布或继续迭代

它更像一个循环系统，而不是“把需求扔给 AI，等它吐一段代码”。

这套闭环带来的直接收益，并不只是更快，还包括更稳：

开发阶段更容易发现缺失的上下文和约束
联调阶段更容易接入外部信息，而不是靠手工搬运
自测阶段可以让 Agent 承担更多重复性验证工作
交付阶段更容易把文档、状态、变更说明一起收口

真正可持续的效率，来自闭环，而不是来自某一次惊艳的生成结果。

更重要的是，这个闭环会反过来重塑工程师的工作方式。你会越来越少把时间花在机械性实现上，越来越多把时间花在设计边界、梳理信息、检查风险和校验结果上。这并不是工作减少了，而是工作从“编码体力劳动”转成了“工程系统设计”。

AI 编程踩坑指南

最后说说我觉得最值得提前提醒的几个坑。

1. 开局不立规矩，后面全是债

项目最开始的模式会被 AI 快速复制。如果前几千行代码的结构、命名、约束和目录都不稳定，后面的产出通常只会把这些问题放大。AI 是个放大器，好的模式会被放大，坏的模式也一样。

2. 长对话不是资产，往往是隐形负债

大概十几二十轮之后，Agent 很容易开始和早期决策冲突。不是它突然变笨了，而是上下文已经漂移了。大任务要主动开新会话，并明确引用之前确认过的结论。很多返工并不是因为模型差，而是因为人误把“持续对话”当成了“持续一致”。

3. “已完成”不等于真的完成

AI 很擅长给出一个看起来完整的答案，但不代表它真的跑通过、验完整。边界情况、异常路径、超时处理、并发问题，依然需要明确验证。只要你开始频繁相信“它说完成了”，你就会很快把 bug 带进后续流程里。

4. 关键逻辑一定要看 diff

有些问题功能测试未必能马上看出来，但在 diff 里会非常明显。越是关键改动，越不能完全跳过变更审查。尤其是数据字段、回退逻辑、权限判断、时间处理这类位置，AI 很容易顺手改出一个看似合理但实际危险的变化。

5. 架构别搞得太花

复杂的多 Agent 编排、过多角色设定、过重的元规则系统，看起来很强，实际维护成本往往很高。大多数时候，简单、清晰、可组合的能力设计更可靠。能用一个 Skill 解决的事，就不要先上一个花哨的总控系统。

6. 一个人能跑通，不等于团队能跑通

个人提效和团队提效不是一回事。真正困难的，是让所有人共享同一套规范、工具和流程，并且能随着项目演进持续更新。一个人靠经验兜住的问题，团队往往会在协作中被放大。

7. 不是所有问题都需要 LLM

确定性的事情就用确定性的程序解决。AI 应该用在理解、生成、总结、规划这些真正需要它的地方，而不是把所有操作都往 LLM 上堆。很多“AI 化”的方案最后之所以成本高、效果差，就是因为本来应该写死的流程，也被强行塞进模型推理里了。

总结：AI 编程不是让你更快地写代码

回看这半年，我越来越确定一件事：AI 编程最重要的变化，不是让你“更快地敲代码”，而是迫使你把更多精力放回工程里真正重要的部分。

也就是这三件事：

设计上下文
设计约束
设计验证

这些事情在手写代码时代就重要，在 AI 参与开发之后只会更重要。

技术在加速，但工程的本质没有变。需求要清楚，边界要明确，结构要干净，验证要扎实。AI 帮你放大的是整个系统的能力，所以你最终得到的，不会只是“更多代码”，而是你设计出来的那套工程方法本身。

如果要用一句话概括我现在对 AI 编程的理解，那就是：它不是把工程师变成“更快的程序员”，而是把工程师推向“更强的系统设计者”。谁能把上下文、流程、约束和验证组织得更好，谁就更有机会真正把 AI 用进生产力，而不是停留在演示和短期惊艳里。