My Digital Worker : New Coding Way
导言
AI浪潮下，一开始是代码补全，之后是Vibe Coding，现在是Agent（规范驱动开发(Spec-driven Development)），后续趋势是Agent Team/Swarm。作为一个程序员，应当以什么姿势拥抱AI时代的代码编程，是需要持续关注的问题。
思想¶
- AI能力越增长，怎么做，谁来做这件事就越不重要。
- 重要的是判断力:知道该做什么，看得出结果好不好，理解系统怎么协作。
AI 化的进程
AI的红利，目前还牢牢锁在科技圈子里面。 Slok直言:「投资者不相信AI会给科技行业以外带来更高利润。」
也有学者泼冷水说，苏菜曼混淆了「任务自动化」和「岗位自动化」。 一个岗位包含十几项任务，AI能替掉三五项，不代表整个人就能被替掉。 洗碗机替代了洗碗，但没有消灭厨师。
《旧金山标准报》在分析Shumer的文章时，写了一句特别精辟的话:颠覆的速度，最终由最慢的那股力量决定，而不是最快的。
思考是核心¶
我和 AI 之间最频繁的互动，是一起想方案，写代码反倒是次要的。一个典型的 session 是这样的：
- 我先口述一个粗略的设计思路——比如“我想把 AReaL 的 rollout 和训练做成异步流水线，rollout 在 inference 集群上跑，训练在 training 集群上跑，两边通过共享存储交换数据”。
- AI 会提出问题：数据格式怎么定义？rollout 失败了怎么重试？训练端怎么知道新数据已经就绪？
- 我回答这些问题，AI 整理成更详细的方案，
- 我再挑毛病，
- 如此反复。同一份设计文档经常经历 v1 到 v5 的演进。
AI的优势¶
- AI 更像是规划放大器，而非编码替代品。 它“见过”的代码库和设计模式远比任何个人多，能迅速给出多种可能的方向并分析各自的权衡取舍——你不一定采纳它的建议，但它把“想的过程”加速了。
- 多文件协同改动则是另一个 AI 明显优于人类的场景。在整个开发过程中，这类任务被标记为“最有价值”的次数最多——37 次。典型场景是：你要统一整个项目的某个参数传递模式，或者把分散在十几个文件里的某个旧接口迁移到新接口。这种任务对人来说最痛苦的地方在于保持跨文件的一致性，每个改动本身不难
- 效果好的场景有一个共同特征：有明确的模式可循、有清晰的验证标准
软件开发必要思想¶
Oh My OpenCode
- Oracle：设计、调试；
- Frontend UI/UX Engineer：前端开发；
- Librarian：官方文档、开源实现、代码库探索；
- Explore：超快的代码库探索（上下文搜索）。
人类软件工程那些方法论让ai用起来也能大幅提升代码质量，tdd，ddd，规范编程，头脑风暴，文档写的比代码多，这些都用上除了项目初期会有阵痛，后面ai真正上手这个项目后代码会写的越来越好
从想法、设计、讨论（Coding Agent 从这里介入），到确定实现方案、编码、E2E 验证，一套流程走完，才算一个 feature 真正完成。
个人并行开发¶
- multitasking——不同 session 处理不同任务，一个跑 plan、一个跑实现、一个做 review，利用等待时间提升吞吐。
- pass@k 采样——同一个问题给不同约束，让多个 session 各自独立探索不同路径，再从中挑选最优方案。两者还可以结合：写代码的 session 带“实现”视角，审查的 session 带“找问题”视角，立场差异能发现自我 review 的盲区。
里程碑式交付¶
- 嵌套式计划。
- 在 AReaL 的开发中，一个复杂任务往往是“大计划中的小计划中的某个 phase”——先让 AI 制定一个高层级的实施方案，把方案拆成多个阶段，每个阶段内部再有自己的子计划。这种嵌套结构的好处是：每一层的 context 都是可控的，AI 不需要在一个 session 里理解整个项目的所有细节，只需要聚焦当前 phase 涉及的文件和逻辑。
- 分批读入、分批写入。
- 与其让 AI 一次性读取 20 个文件再一口气改完，不如分成几批：先读前 5 个文件，理解这部分的模式，做完改动；再读下一批。大的代码改动同理——写入也分批进行，每批改完后做一次验证，确认方向没偏再继续。这样每一步的 context 都保持精简，AI 的输出质量也更稳定。
- 每个子任务要有明确的输入、输出和验证标准。
- 模糊的任务描述（“优化一下这个模块”）会让 AI 无所适从；而“把 sync_weights 从同步调用改为异步调用，输入不变，输出改为 Future，用 test_async_sync.py 验证”这样的描述，AI 可以精准执行。验证标准不是可选的附加项，它是每个子任务定义的一部分——这直接引出了下一个核心实践。与此相关的一个细节是：要站在 AI 的角度设计环境——避免 context 污染（不混杂不相关的任务）、让日志格式机器友好。
构建Agent专家¶
规划和验证解决了“做什么”和“怎么判对错”，但还有一个问题：谁来执行？
通用 AI 在垂直领域的深度不够，需要更专业的角色分工。前面提到了按领域划分的 agent，这也是 AReaL 工具链中经过充分验证的部分。
解决方案是为每个关键领域配置专门的 expert agent。
- 每个 agent 的 prompt 携带该领域的知识图谱——核心概念、配置约束、常见踩坑点、诊断流程、关键文件路径。
- 比如 FSDP 专家携带 sharding 策略的组合约束和 OOM 诊断流程，
- RL 算法专家理解 PPO/GRPO/DAPO 的超参交互，
- 集群调度专家能根据报错症状定位是 GPU 分配还是跨节点通信故障。
- 这些 agent 不只是知识库，更是诊断手册——像经验丰富的同事一样，先确认上下文，再按流程逐步缩小范围。
- Claude Code 的 Agent Teams 功能在设计目标上与此相似，但为特定代码库量身定制的专用 agent 携带了更具体的领域知识，效果更优。
文档化¶
重视规划，正确拆解需求 — AI 是规划放大器，不是编码替代品。放大格局，但每个子任务要有明确的输入、输出和验证标准。
当前AI的记忆能力不足，每个功能需要开发写对应的《需求设计文档》《特性设计文档》
文档整理¶
把信息按性质分层。最终 AReaL 的 CLAUDE.md 瘦身为一个精简的入口文件，只包含
- 项目简介、
- 技术栈、
- 目录结构、
- 基本开发命令，
- 以及一组底线约束（Always Do / Ask First / Never Do）。
- 在有疑问时，总是询问细节，询问时需要提供完整的可选项；
- 新功能和特性开发需要编写对应《需求分析文档》《需求详设文档》《测试看护文档》，默认路径是 docs/ai/{特性名称}.md， 如果已有文档需要补充完善。
- 新功能和特性开发需要有对应的测试案例。
- 需要遵循TDD的开发思路，先编写测试样例，再开发程序功能，保证测试样例通过再继续开发，如此循环直至满足所有要求。
- 同时它还承担“路由”的角色：用一张表指引 AI 按需去找深层信息
- 添加 Workflow 去看 docs/customization/agent.md，
- 添加 Dataset 去参考 areal/dataset/gsm8k.py，
- 了解算法细节去看 docs/algorithms/。
真正的细节知识被拆分到了四层：
- rules/ 放全局约束，按路径自动匹配加载。比如 distributed.md 只在改动引擎代码时才激活，里面编码了分布式开发的硬性规则（如“allreduce 必须被同一 group 的所有 rank 调用”），甚至附带了常见故障对照表——Hang 多半是 collective call 不匹配、OOM 多半是 DTensor placement 不对。
- agents/ 放领域专家，按需激活。AReaL 配置了 FSDP 引擎、Archon 引擎、Megatron 引擎、RL 算法、集群调度等专项 agent，以及代码审查和代码验证 agent。处理分布式问题时 FSDP 专家被激活，讨论 GRPO 实现时算法专家上场。后文“专业 Agent 分工”一节会详细展开。
- skills/ 放可复用流程，尝试标准化重复性任务。比如“添加新的 reward function”或“添加新的 dataset loader”的引导流程。这些目前还是实验性质的——思路是把操作步骤编码成引导流程，让 AI 按正确的顺序做事，而不是从零摸索。
- commands/ 放用户可直接调用的动作，比如 /create-pr 自动 rebase、squash 并创建 PR，/gen-commit-msg 根据 staged changes 生成提交信息，/pr-review 做动态 code review。这些是日常开发中使用频率最高的自动化入口，后文“动态 Code Review”一节会展开 /pr-review 的设计。
这些文档同时也是 AI 的“记忆系统”。单个 session 的上下文窗口是有限的，跨 session 的信息更是默认丢失。但 rules/、agents/、设计文档这些文件是持久化的——它们让每一个新 session 都能“记住”之前踩过的坑和积累的经验。
TDD¶
测试来保证功能的稳定性，防止后续AI修改破坏原本的功能。
- 多层验证防线：我的验证体系最终稳定为多层防线。
- 第一层是 pre-commit hook，自动跑格式化和 lint，拦住最基本的低级问题——代码验证 agent 会在每次改动后自动执行这些检查。
- 第二层是 /pr-review 的动态审查（详见后文“动态 Code Review”一节），利用领域专家 agent 对改动做针对性的代码审查，比通用 lint 深入得多。
- 第三层是 CI/UT 随着项目变大，针对新发现的失败模式持续补充测试。这和社区里其他大型 AI 辅助项目的做法一致：不断扩展 CI pipeline，每次发现“新功能破坏了旧代码”就补上对应的回归测试，形成滚雪球式的质量积累。
- 最小可复现 demo
- 重视 evidence，用最小 demo 驱动长周期任务与调试 — LLM 只能理解代码可复现的 evidence。先设计验证方案再写代码；遇 bug 先提炼最小 demo。
代码审查¶
- /pr-review 的核心设计理念是动态 agent template
- 它会根据 PR 内容自动组装专家团队，而非用一个固定的 reviewer 包打天下。
- 具体来说：系统先分析 PR 改动了哪些文件，按风险等级（CRITICAL / HIGH / MEDIUM / LOW）分类，然后从模板库中选择对应的专项审查任务，分配给不同能力层次的模型
- 关键路径用最强的模型做深度审查，低风险改动用轻量模型做基本检查。
- 所有审查任务并行执行，最终汇总为带置信度评分的结构化报告。
这个设计在真实开发中的效果是：我现在几乎不用自己太认真地 review 了。人的精力被聚焦到了最需要判断力的地方。更重要的是，审查模板里编码了大量领域知识，这些知识在每次 review 中都被自动应用。某种意义上，/pr-review 把团队的集体经验变成了可执行的检查清单。1