企业官网建设流程全解析

1. Agent 写完了代码，真正的战场才刚开始

过去大半年，我身边越来越多团队开始把 Agent 接进日常开发流程。最典型的场景是：你给一个编程 Agent 描述清楚需求，它刷刷刷地生成几百行代码，甚至能自己跑测试、改 bug，最后丢给你一个“看起来能跑”的仓库。不少朋友第一次看到这一幕时，兴奋劲儿跟当年第一次用 Copilot 自动补全差不多。但等真正把 Agent 写的代码合进主线、部署上线，问题才一个一个冒出来：代码风格跟团队规范对不上、依赖版本混乱、逻辑只有 Agent 自己懂、安全审查根本不通过……这时候大家才意识到一个残酷的事实——Agent 把代码写完了，然后呢？

这篇文章想聊的就是这个“然后”。我会结合自己实际踩过的坑，把 Agent 写完代码之后的一系列问题拆开来讲：验收要看什么、怎么审查、怎么处理 Agent 特有的记忆和上下文问题、怎么保证后续迭代还能继续用 Agent 而不是推翻重来。无论你是刚接触 Agent 开发的新手，还是已经在团队里推行 Agent 辅助编程的负责人，这篇文章都能给你一份可以直接照着做的检查清单和经验参考。

先说明一下我的背景：我日常主要用 Python 做量化交易策略开发，也维护过几个基于开源大模型搭建的编码 Agent 框架，所以文中会大量出现 Python、Agent 框架、代码诊断这类具体例子。这些经验放到 Java、Go 或者前端项目里同样适用，核心思路是一致的。

2. 为什么“写完代码”不等于“做完需求”

2.1 Agent 的完成标准是“通过测试”，不是“满足需求”

我见过最典型的一个案例：团队让 Agent 写一个用来拉取行情数据的模块，Agent 生成了完整代码，单元测试也通过了，看起来一切正常。结果联调的时候发现，Agent 把交易所 API 的限频机制完全忽略了——测试用的是 mock 数据，当然怎么跑都通；到了真实环境，一分钟内请求次数超过限制，直接触发风控，整个策略服务瘫痪。

这种问题的根源在于：Agent 的“完成”定义通常来自你给它的任务描述和它自己能做的验证手段，而不是你对需求的完整理解。它不会主动问你“这个接口有没有限频”“这台服务器上有没有装 Redis”“这段代码要兼容 Python 3.8 还是 3.12”，它只会按照 prompt 里的字面意思把功能做出来，然后跑一遍它能跑的通测试。

所以在验收 Agent 写的代码时，第一件事就是调整心态：Agent 交出来的代码只是一份“初稿”，而不是可以直接上线的最终产品。你得像面试一个刚入职的初级工程师一样，从头到尾 review 一遍，甚至比 review 初级工程师更仔细，因为初级工程师至少还懂你们团队约定俗成的规则，Agent 是真的什么都不懂。

2.2 上下文窗口：Agent 的“记忆力”没有你以为的那么好

现在主流 Agent 框架都会引入长期记忆、向量数据库这些机制，让 Agent 在多次会话之间保留关键信息。但我在实际使用中发现，所谓的“记忆”更多是存储层面的，理解层面的记忆仍然很弱。

举个例子：我让 Agent 基于某个已有的量化策略框架新增一个均线交叉信号。第一次对话，它正确引用了我项目里已有的Position类。隔了两天，我继续就同一个策略提新需求，它却给我重新定义了一个Position类，跟原来那个功能重叠但接口不完全兼容，差点导致整个回测引擎跑不起来。

原因很简单：对话历史太长之后，Agent 会把早期内容“遗忘”或压缩，尤其当这些内容不在当前上下文窗口的重点位置时。向量数据库能帮助检索，但检索到的是片段，不一定能重建出完整的“当前项目状态”。所以你自己必须维护一份“项目状态说明”，每次让 Agent 动手前，把当前目录结构、关键模块接口、依赖版本、已有哪些功能，全部明确写进 prompt 里。

我后来养成的习惯是：项目根目录里放一个AGENT_CONTEXT.md，每次会话开始先让 Agent 读这个文件，再谈具体任务。里面不写废话，就写模块清单、接口签名、依赖约束、代码风格要求。实测下来，Agent 跑偏的概率低了很多。

2.3 “看起来能跑”和“真正能用”之间的鸿沟

还有一个被低估的问题：Agent 生成的代码往往在自己创建的隔离环境里跑得很欢，但一旦放到你的真实项目里，各种环境依赖问题就冒出来了。

最典型的是 Python 项目的依赖管理。Agent 可能会用到一个你项目里根本没装的库，并且不会主动告诉你“我用了这个新库”。等你拿到代码一跑，直接ModuleNotFoundError。更隐蔽的是版本冲突：Agent 在测试环境用的numpy是 1.24，你项目锁的是 1.21，很多 API 在 1.22 之后就变了，结果就是回测结果微妙地不一样。

这类问题没法靠 “让 Agent 更强大” 来解决，只能靠流程来兜底。后面我会专门讲依赖和环境的管控方式。

3. 拿到 Agent 代码后的第一轮“人工审查”

3.1 设计一个人的验收清单模板

如果你只是把 Agent 生成的代码往项目里一粘，那我建议你停一停。我在实际项目里总结了一份验收清单，每次让 Agent 完成一个模块之后，我都会对照清单逐项打勾，全部通过才算真正完成。

这份清单大概长这样：

这份清单不是凭空想的，每一条背后都有对应的翻车教训。比如“接口兼容”那条，就是我在前文提到的重复定义Position类之后加上的；“异常处理”那条，则是一次抓取行情数据时没处理断网重连，直接把整个策略搞崩。

3.2 代码审查里的 AI 痕迹怎么识别

这里聊一个比较玄但很实用的经验：Agent 写的代码其实有“指纹”。多看几次之后，你一眼就能认出来。

常见特征包括：注释写得太“教科书”——每段逻辑前都有一句解释，仿佛在给小学生讲题；函数命名特别长，恨不得把整个功能描述都塞进函数名里；喜欢用非常普适的设计模式，引入一堆不必要的抽象层；变量名带着_temp、data1、result2这类后缀，明显是迭代调试时没清理干净。

这些特征本身不一定是问题，但可以帮助你提高警惕：看到这种代码，就要多想想“它为什么这么写”？如果某个抽象层纯粹是 Agent 为了展示设计能力而加的，而不是项目真实需要的，我建议直接删掉。项目后期，每一层不必要的抽象都是维护成本。

另外，Agent 经常过度设计。你只让它“写个函数计算两个数的和”，它能给你搞出一个包含策略模式、依赖注入、日志装饰器的完整框架。不是说不可以用这些高级写法，而是要问一个问题：这个项目现在真的需要吗？不需要的话，宁可是“全宇宙最土的写法”，只要清晰稳定能跑，好过花架子。

3.3 运行测试的姿势比测试本身更重要

在审查 Agent 代码时，你得注意它的“自证陷阱”。Agent 通常会在完成任务后顺手写一堆测试来证明自己的代码没问题，但这些测试很可能是“怎么实现就怎么测”，根本没有检验业务逻辑是否正确。

我举个具体例子：让 Agent 写一个交易信号生成函数，它可能写个测试，验证“当短期均线高于长期均线时返回买入”。这个测试确实覆盖了函数行为，但如果你希望的逻辑是“短期均线上穿长期均线时才买入，而不是持续高于就买入”，Agent 的测试和实现就一起跑偏了。测试通过了，但业务逻辑是错的。

所以我在每轮验收时，都会手工构造几个我自己设计的关键用例，不提前告诉 Agent，直接拿它的函数跑，看输出是否符合我的业务预期。尤其关注边界：价格序列长度只有 1 时怎么办？全是 NaN 时怎么办？两个均线值相等时怎么办？这些边界一旦在测试里覆盖住，代码的鲁棒性就肉眼可见地提升了。

4. 让 Agent 代码融入项目的关键步骤

4.1 先解决依赖和环境的“青蛙效应”

“青蛙效应”是我自己发明的说法：刚开始 Agent 用的新依赖只有一两个，你手动装一下还行；但每轮迭代它都引入一两个新依赖，十轮下来，你的环境就变成了一锅你自己都不认识的粥。最糟糕的是，这些依赖之间还会打架。

我现在处理依赖的核心原则是：Agent 不允许直接改依赖文件。它可以在代码里 import 任何东西，但依赖文件的变更必须由我来审查并手动合并。每次 Agent 提交代码后，我会跑一遍git diff requirements.txt，看到新增依赖，先问三个问题：这个库是不是真的必要？有没有项目里已有的替代品？新版本会不会跟现有库冲突？

如果是 PyTorch、pandas 这类重依赖，我还会在干净环境里新建一个虚拟环境，重新安装并跑一下 Agent 的代码，确认能复现。这一步看起来很麻烦，但能避免大量“在我机器上跑得好好的”的悲剧。

从需求阶段就明确依赖约束也很重要。我现在每个任务 prompt 都会加一句：“优先使用项目现有依赖，如确需新增依赖，请在交付说明里单独列出并说明理由。”Agent 会照做的比例相当高。

4.2 用框架的“技能”和“工具”约束 Agent 的行为

如果你在用比较完整的 Agent 框架，应该听过“Skill”和“Agent”这两个概念。简单理解：Agent 是“大脑”，负责理解任务、规划步骤；Skill 是“工具箱”，提供特定领域内现成的方法和工具，Agent 只能从 Skill 里面选，而不是自由发挥。

我在让 Agent 写代码时，会尽量把项目里已有的工具函数做成一两个 Skill 暴露给它。比如“获取K线数据”“计算技术指标”“下单交易”这几个动作，都封装成固定函数，Agent 的任务只是编排这些函数的调用顺序，而不是自己重新实现一遍。这样有几个明显好处：

• Agent 生成代码的接口风格会自然地和现有代码保持一致；
• 关键逻辑已经在 Skill 里经过了人工验证，Agent 不会在底层乱改；
• 就算 Agent 编排错了，错误范围也被限制在它的编排层，排查起来容易得多。

很多 Agent 框架（比如开源社区的几款主流框架）都支持自定义工具注册。配置 Skill 的过程也很简单：写一个函数，加一段描述说明这个函数是干什么的、参数怎么填、返回什么。注意描述要简洁清晰，因为 Agent 是靠描述来理解该什么时候调用你的函数的，描述写得含糊，它就会瞎猜。

4.3 版本控制里的“Agent 提交”如何管理

Agent 直接在代码库里提交代码是我一开始特别抵触的一件事。后来我制定了一条规则：所有 Agent 生成和修改的代码，都以“补丁”的形式提交，由人工审阅后再合入主干。具体操作：

1. 在独立分支上让 Agent 做开发；
2. Agent 完成后，用git diff生成补丁文件；
3. 人工（我或团队里其他人）下载补丁，在本地代码上应用；
4. 应用后在本地跑测试、人工 review，确认没问题才合入主干。

这样做还有一个额外好处：因为 Agent 生成的代码不会直接污染主干，团队成员在 review 时可以大胆提修改意见，让 Agent 去迭代，而不是迁就 Agent 写出来的问题代码。每轮迭代都生成新的 diff，老 diff 作废，主干始终保持只有人工确认过的代码。

我自己的习惯是给 Agent 开一个agent-dev分支，分支名永远是固定的，方便清理。每次会话结束后，如果 Agent 已经提交过代码，我会git reset --soft master把提交变成未暂存的更改，然后审视这些更改。

4.4 把人工审查结果反馈给 Agent，形成迭代闭环

大多数 Agent 框架支持多轮对话，这意味着你可以把 review 意见直接丢回给 Agent，让它自己改。真正的关键在于反馈的质量。

“这里有点问题”这种模糊反馈基本无效。你得说：“fetch_data函数里请求超时设为 3 秒太短，在弱网环境下很容易失败，请改为 10 秒，并增加指数退避重试逻辑。重试次数最多 3 次，失败后返回空 DataFrame。” 这种具体反馈，Agent 才能精准修改，而且大概率一次改对。

我通常会把审查意见按优先级排序，一次只让 Agent 改最关键的两三条。不要一次丢给它十个问题，它的上下文处理能力有限，改着改着就把前面的要求忘了，或者为了满足一大堆需求引入新的 bug。小步快跑，多轮迭代，最后得到的结果质量通常比一次大改要高很多。

这个“审查-反馈-修改-再审查”的闭环，其实是整个 Agent 辅助开发流程里最核心的引擎。Agent 的能力决定上限，而这个闭环的效率决定你实际能拿到的成果。

5. 实操实录：一次完整的量化策略代码生成与验收

5.1 场景设定：让 Agent 写一个双均线策略信号模块

为了让你直观感受完整流程，我拿最近做的一个量化交易策略开发项目来举例。背景很简单：我要在一个已有回测框架里新增一个双均线策略的信号模块，输入量价数据，输出多空信号。项目本身已经有依赖管理（pyproject.toml），也有基础的工具函数，比如calculate_ema。

我给 Agent 的任务 prompt 大概是这样的：

项目背景：这是我们的A股日线回测框架，技术栈Python 3.10 + pandas + numpy。 请阅读 AGENT_CONTEXT.md 了解现有模块和接口。 任务：新增一个双均线策略信号模块。 - 输入：DataFrame，包含 date, open, high, low, close, volume 列。 - 输出：DataFrame，包含 date, signal，其中 signal 取值为 1(多)、-1(空)、0(观望)。 - 策略逻辑：计算 5 日均线和 20 日均线，当 5 日均线上穿 20 日均线时信号为 1，下穿时信号为 -1，其余时刻为 0。 - 暂不引入新依赖，优先使用项目已有工具函数。 - 请用中文写出关键注释，并补充关键边界条件的处理。

5.2 我观察到的 Agent 行为与问题

Agent 很快交出了代码，结构还算清晰，函数命名也挺规范。但我 review 时发现三个问题：

第一个，它在计算均线时，直接用了 pandas 的rolling().mean()，这没问题，但它没有对数据量不足 20 行的情况做处理——当输入只有 15 行数据时，rolling(20)会产生 NaN，而它的信号判断逻辑遇到 NaN 直接报错。这是典型的边界条件遗漏。

第二个，它对“上穿”和“下穿”的实现是拿今天的均线值和昨天的均线值做差，这方向是对的，但它没有考虑历史上曾经发生过金叉死叉后又震荡的情况。如果今天均线值正好相等，它的判断逻辑会产生错误信号。我要求的是明确的穿越，而不是“大于等于”这种模糊状态。

第三个，它自作主张在函数里加了一个print日志，虽然无伤大雅，但在生产回测循环里打印大量日志会严重影响性能，而且不符合我们仓库的规范。

这些问题单独看都不严重，但如果不 review，直接合入，后面跑回测时排查起来就非常费劲。所以我的处理方法是：把这三个问题写成清晰的修改意见，逐条反馈给 Agent。

5.3 第二三轮迭代：边界处理与代码精简

第二轮，我给的反馈是：

1. 当输入数据不足 20 行时，请返回全 0 信号，不要抛异常。 2. 上穿下穿的判断应使用严格不等式：今天5均线 > 今天20均线 且 昨天5均线 <= 昨天20均线 视为金叉。 3. 删除所有 print 日志，改用项目统一的 logging 模块，并把日志级别设为 DEBUG。

Agent 第二轮产出好了很多，边界处理也加上了。不过我注意到它在处理“昨天均线”时，用了shift(1)，但shift之后第一行会变成 NaN，它在判断里没有排除这种情况。第一行数据本身也不该产生信号，否则策略在第一天就会莫名开仓。

于是第三轮，我进一步补充：

注意 shift(1) 导致的第一行 NaN：第一行 signal 必须为 0。

到第三轮，代码终于基本符合要求。我拿它跑了当时的数据，跟手写版本对比，结果一致。这次整个迭代过程大概花了四十分钟，其中我自己的 review 和反馈占了七成时间。这就是 Agent 写代码的真实成本——写代码只占一小部分，验收与反馈才是大头。

5.4 从这份实操里能复用的方法论

从上面这个过程，我提炼了几条方法论，适用于大部分 Agent 写代码的场景：

• 任务描述里必须写清“不做什么”，比如“不要新增依赖”“不要 print”，这比写“做什么”更能防止 Agent 跑偏。
• 边界条件的坑，Agent 几乎必踩。你在 review 时最优先检查的就是边界：空数据、极短数据、相等值、缺失值、重复值。
• 每轮反馈只聚焦最关键的几个问题，让 Agent 小步迭代。
• 验证 Agent 生成的信号逻辑时，拿一小段你手工构造的数据去跑，别依赖 Agent 自测的结果。
• 如果同一处错误反复出现，那说明你的 prompt 或 Skill 配置有问题，该去改基础设施而不是继续骂 Agent。

6. Agent 遗留的“技术债”怎么还

6.1 认知债：你的团队真的理解 Agent 写的代码吗？

Agent 写代码最大的隐形代价，不是代码本身，而是团队对代码的认知缺失。你让一个 Agent 生成了一个复杂的策略模块，代码能跑，收益也不错，但三个月后你想改一下参数，发现自己已经忘了这个模块内部的设计逻辑，Agent 的记忆可能也已经被新的会话覆盖了。这时候你面对的是一段“能跑但没人懂”的代码，这是比技术债更致命的认知债。

我的应对办法是：每一次让 Agent 完成任务，都强制它产出一份“设计说明”。这份说明包括：模块的输入输出、关键函数的作用、使用了哪些外部依赖、有哪些边界处理、为什么选择当前的实现方式。这份说明不需要很长，但必须真实。以后任何人（包括未来的你）接手这个项目，先读设计说明，再读代码，效率至少提升一倍。

如果 Agent 不给设计说明，我会根据代码自己写，然后把 Agent 叫回来，让它补充缺失部分。虽然这一步看起来增加了工作量，但从长远看，它防止了这个项目变成“遗产代码”。

6.2 数据债与缓存坑

量化交易场景里，数据债特别刺眼。Agent 在写数据获取模块时，经常会顺手加入本地缓存机制来提升性能，比如把K线数据缓存成 CSV 或者 parquet 文件。这本意是好的，但 Agent 不会考虑缓存失效的问题：它可能把缓存键设置为股票代码，但忘了把时间范围或复权方式放进去。结果是你换了一组时间参数，命中的却是旧缓存，整个回测结果都是错的。

这类问题隐蔽性极强，因为程序不会报错，数据也有，只是结果不对。我后来的规避方式很粗暴：Agent 提交涉及数据读写的代码时，我要求它必须显式地在代码里标明缓存键的组成要素，并且在设计说明里说明缓存何时失效。如果它做不到，我就直接把它写的缓存逻辑删了，宁可用笨办法每天全量拉数据，也不要在回测里吃数据更新的亏。

6.3 安全债：Agent 写代码时的“无心之失”

安全这块必须单独拎出来说。Agent 不会故意作恶，但它对危险代码的敏感度远比资深工程师低。最常见的安全隐患包括：把 API key 或数据库密码硬编码在代码里；在日志里打印敏感数据；SQL 查询用字符串拼接而不是参数化；使用pickle反序列化不可信数据；直接执行外部传入的 shell 命令。

我自己在审查 Agent 代码时，每一步都会带一个“安全视角”。不用很复杂，平时用grep搜几个关键词，比如password、secret、api_key，看看有没有可疑的常量，基本上能过滤掉大部分硬编码密钥。如果你用 GitLab 或 GitHub 系的产品，直接在 MR/PR 阶段加一个自动扫描的插件，或者在 CI 里挂一个开源扫描工具，一旦发现疑似密钥就阻断合入。这不是针对 Agent，对所有代码都适用，但 Agent 代码中这类问题出现的概率真的高。

另外提醒一句：如果你的 Agent 框架支持联网搜索或调用外部工具，那你就得更加警惕“提示注入”问题。恶意网页内容可能包含构造性的指令，诱导 Agent 按恶意意图生成代码。所以如果 Agent 要联网获取资料，最好让它在沙箱环境中运行，禁止它把未经校验的外部内容直接拼接进代码或命令。

7. 常见问题与排查避坑记录

7.1 为什么 Agent 生成的代码在我本地运行报错？

这个问题几乎每个人都会遇到。排查顺序应该是：

• 先看是不是依赖问题：拿requirements.txt或pyproject.toml与 Agent 运行环境对比，检查版本差异。最简单的方法是pip freeze对比。
• 再看路径问题：Agent 可能在绝对路径或相对路径上跟你预期不一致，尤其注意读取数据文件的部分。
• 接着看 Python 版本差异：有些语法或 API 在 Python 3.10 和 3.12 之间行为不同，Agent 很可能默认它熟悉的新版本语法，而你的环境是旧的或反过来。
• 最后看隐藏的配置文件：Agent 可能隐式依赖了某个环境变量或本地配置文件，而你这里没有。

7.2 Agent 写的测试全通过了，但我的业务场景还是挂了？

这就是经典的“测试偏差”。Agent 的测试只验证了它自己理解的行为，而不是你的真实需求。解决方式就是我在第 4 节讲过的：用你手工构造的用例去验证。你可以准备一份专门的“验证用例集”，每次只让 Agent 写代码，不让它写针对该代码的测试，你用统一验证脚本在它的代码上跑，然后对拍结果。对拍通过才算数。

7.3 “Agent execution terminated due to error”这类错误怎么处理？

这个报错在不少 Agent 开发框架里都很常见。意思简单说就是 Agent 在某个执行步骤里崩了，可能是调用的工具出错、代码执行超时、内存溢出，或者 Agent 自己在生成过程中产生了不符合预期的格式导致解析失败。

我的排查经验是：

• 先把日志打开，找到崩溃前的最后一步操作，通常问题出在那一步的输入参数上。
• 如果是代码执行超时，检查是不是某段死循环或者数据量过大。
• 如果是工具调用失败，重点看工具描述和 Agent 传给工具的参数是否匹配。
• 如果报错内容里带了“Exit code”之类的信息，直接看那段子进程的错误输出，比看 Agent 日志快得多。

这类问题很多时候不是你写的代码 bug，而是 Agent 框架本身的编排问题。这时候别去 review 业务逻辑了，先修通道。

7.4 常用排查工具与配置参考

我目前日常在用的辅助工具有这些，供你参考：

这些工具配上第 3 节的验收清单，基本能把 Agent 代码的常见坑拦住八成以上。剩下的两成，主要靠你自己对这个业务领域的理解来兜底。

8. 后续迭代时，如何让 Agent 持续可用而不是“一把梭”

8.1 建立“项目状态快照”机制

如果你想在一个长期项目里持续使用 Agent，那“项目状态快照”机制几乎是必须的。我在每个项目里维护一个docs/agent_state.md，每次会话开始前让 Agent 阅读，确保它对项目现状的理解是新鲜的。

快照内容不需要长，但必须包含：

• 当前目录结构与核心模块的职责；
• 已经完成的功能清单和未完成的功能清单；
• 关键接口签名与数据结构；
• 依赖管理规范，比如允许新增依赖的限制条件；
• 代码风格要求与测试运行命令。

每次会话结束后，我会把本次改动同步进快照。这个过程本身也是复盘：如果 Agent 改了某个接口设计，快照里的接口签名必须同步更新，否则下次会话它就会用旧的接口写出错误代码。

8.2 Skill 库的沉淀与复用

随着一个项目里的 Agent 任务越做越多，你会发现很多功能是重复的。比如“获取日线数据”“计算均线”“生成回测报告”这些动作，如果每次让 Agent 重新写一遍，等于每次都在踩同样的坑。

正确做法是：把经过验证的工具代码沉淀成 Skill。Skill 不仅仅是函数，还要有清晰的使用说明和示例。沉淀 Skill 的过程有点像写公司内部的基础库，但更轻量：你不需要保证它能处理所有场景，只需要保证在当前项目场景下稳定可靠。

Skill 复用之后，Agent 的角色逐渐会从“程序员”变成“胶水脚本编写者”：它不再负责实现底层逻辑，而是负责把经过验证的积木组合起来，完成你的指令。这样它的出错率会大幅下降，你的审查成本也会大幅下降。这也是“Agent 写代码”走向“Agent 帮你整理代码”的必经之路。

8.3 人机协作的节奏感：什么时候该让 Agent 做

很多团队纠结“要不要让 Agent 写代码”，我个人的观点是：区分任务类型比一刀切更重要。

适合交给 Agent 的任务：模式清晰、边界明确、可验证的模块开发，比如写一个数据清洗函数、封装一个 API 客户端、生成一个报表脚本。这类任务即使 Agent 写得有瑕疵，也容易通过测试发现。

不适合交给 Agent 的任务：需要深入理解业务背景、涉及多方权衡、或者带有大量隐性约束的设计决策。比如策略的整体架构该怎么设计、数据源失联时的回退方案该如何取舍、哪些功能必须人工复核，这些事交给 Agent 很容易得到“看似合理但实则偏颇”的结果，而偏颇的代价往往要到很久之后才显现。

我现在的节奏是：重大项目开会，Agent 负责记录；架构设计我拍板；具体模块 Agent 写；代码质量我验收；验收意见 Agent 改。这套流程跑顺之后，我的产出速度比单打独斗时快了不少，而且没觉得质量下降。

9. 关于“然后呢”这个问题的最终体会

抛开工具和流程，我最大的感受是：Agent 把代码写完了，真正重要的是“人有没有跟上”。Agent 可以帮你把想法变成初稿，但它不会替你理解这个项目的过去和未来。代码能不能合入、能不能上线、能不能长期维护，最终取决于你有没有建立一套能约束 Agent 的流程，以及有没有持续地把关键信息沉淀下来。

我自己在过去几个月里，最大的收获不是“Agent 帮我写了多少行代码”，而是“为了管好 Agent 写的代码，我把原来稀里糊涂的项目规范、依赖管理、测试体系都补上了”。这个副作用远比代码本身值钱。如果你也正在被“Agent 写完代码”之后的事搞得焦头烂额，不妨先别急着骂 Agent，试着把事情拆成上面这些环节一件件解决。你会发现，这些步骤其实也是在帮你把整个团队的专业度再往上推一个台阶。

最后分享一个我常对团队里新人说的小建议：拿到 Agent 代码后，你至少要能解释清楚其中每一行是干嘛的，哪怕解释得比较粗。如果有一天你发现自己解释不了了，那就说明这个 Agent 的产物已经超出你的掌控范围，这时候千万别硬着头皮合入。代码可以慢慢改，认知债攒起来，后面还起来十倍都不止。