企业官网建设流程全解析

AI 编程助手实战指南：让 Coding Agent 真正替你干活的十个工作流

LLM 系列又一篇。前面讲的都是自己造 Agent，这篇换个角度——用现成的 Agent。Claude Code、Codex、pi 这类 coding agent 谁都在用，但大部分用法只发挥了一半价值。十个实战工作流，全是可复制的习惯。

一、先想清楚：coding agent 就是系列第一篇的 Agent

Claude Code 的本质 =第一篇那 60 行的 ReAct 循环+ 专用工具集（读改文件、跑命令、搜索）+ 权限壳（第六篇 Harness）。理解了这个，它的每个行为都能解释：

• 为什么它先读文件再改——循环里的「结果回填」
• 为什么让它列计划——上下文窗口有限，先对齐再动手
• 为什么改完要跑测试——它的循环不会自动验证，要你给闸门

用 agent 的核心不是「会提问」，是「会设计工作流」。下面十条按优先级排。

二、十个工作流

1. 上下文喂法：先探索，再动手

坏习惯：打开就喊「帮我实现 XX 功能」。agent 对代码库一无所知，只能瞎猜文件结构。

好习惯：先让它读，再让它改。「先看这个模块的结构，理解现有实现，然后告诉我你打算怎么改」——它探索完给出的方案质量完全不同。大任务更进一步：先要 plan，确认了再放行（省返工，也省 token——成本篇的逻辑）。

2. 任务拆解：一个 agent 会话干一件事

「把整个项目重构了」这种指令，agent 会在几十个文件间迷路。一个会话只干一件事：改一个模块、修一个 bug、加一个功能。干完验证、提交，再开下一个会话。

这就是系列多 Agent 篇的原则在自己工作流里的应用：任务可拆就拆，每步干干净净。

3. 验证闭环：改完必跑测试

agent 说「改好了」不等于改好了。永远给它一个验证闸门：

改完之后： 1. 跑测试套件（有测试的项目） 2. 没测试就让它写一个最小验证脚本（评测篇的逻辑） 3. 非平凡逻辑：留一个 assert 自检或 test_*.py

没有闸门的 agent 工作流是「改了但不知道改对没」——和没有评测集的 LLM 调优一样是玄学。

4. 规则文件：把团队规范写进项目根目录

CLAUDE.md/AGENTS.md这类规则文件就是系列 Skill 篇的活例子：知识按需加载。把构建命令、代码规范、目录结构写进去，每次会话 agent 自动带上：

# AGENTS.md - 构建命令：pnpm build && pnpm typecheck - 代码规范：见 docs/CONVENTIONS.md，改代码前先读 - 禁止：不要动 legacy/ 目录，不要升级依赖版本

没有规则文件，agent 每次都要重新猜你的项目约定——猜错就是返工。

5. 会话持久化：别每次都从零开始

接记忆篇：跨会话的记忆靠外置存储。coding agent 的等价物：长任务用会话恢复（Claude Code 的--resume、pi 的任务记忆），项目级上下文写规则文件。每次会话结束前，让 agent 把「本次做了什么、下次从哪继续」写进一个 NOTES.md——手动版长期记忆，零成本。

6. 委派子任务：大任务并行跑

系列多 Agent 篇的「主管-工人」模式在工具里都有现成实现：Claude Code 的 sub-agent、pi 的并行任务。互不依赖的子任务（同时调研三个库、分别改两个模块）拆给并行 agent，串行干一半时间就够。

记住前提：子任务互不干扰才并行，有依赖的串行（踩坑篇老话）。

7. Diff 审查：提交前必看它改了什么

agent 的改动默认比你想象的大。提交前看 diff：改动的文件数对不对、有没有动不该动的、有没有偷偷「顺手优化」。规则文件里写「只改我要求的文件」，能压住大部分越界——但审查这道闸不能省（安全篇的逻辑：写操作过人审）。

8. 版本控制：小步提交，随时可回滚

agent 改砸了怎么办？git 是你的回滚保险。工作流：agent 每完成一个子任务就 commit 一次，message 说清干了什么。改砸了 revert 那一步，不折腾。和评测篇「通过率掉 5% 就回滚」一个道理——回滚的成本必须低于返工的成本。

9. 成本意识：大任务先算 token 账

成本篇的账本直接适用：agent 一个大任务几十次 API 调用，输入是大头。三个习惯：大任务先要 plan 再放行（避免白跑）、无关文件别让它读（省上下文）、能用小模型干的探索类任务别用旗舰（分级路由）。

10. 让 agent 解释，而不只是执行

被低估的一招：让它边干边解释。「你为什么选这个方案？和 X 相比好在哪？」——解释的过程会暴露它的错误假设，比改完才发现省得多。这也是你学它思路的过程：看多了高手的取舍，自己写代码也会变好。

三、十个工作流的优先级

四、踩坑提醒

1. 「全自动放权」是最大误区：agent 没有闸门就会一路狂奔——验证、审查、回滚三道闸缺一不可
2. 上下文是有限资源：一个会话塞太多任务，agent 会忘掉早期的约定（记忆篇的逻辑）——拆会话
3. 别迷信它的「已完成」：没有验证的完成不是完成，跑一遍才算数
4. 规则文件要版本化：AGENTS.md 和代码一样进 git review，团队规范漂移比 agent 出错更隐蔽

总结

coding agent 的能力上限是工具和模型决定的，你的产出上限是工作流决定的。结合系列：它就是第一篇的 Agent、第六篇的 Harness、第四篇的 Skill 在真实产品里的合体——理解了原理，用起来才知道每个功能为什么在那。觉得有用点个关注。