锻造——Agent工程开发方法论
Agent开发不是写提示词——是造一套生产线。锻造是这个生产线的操作手册。
名字来源于铁匠比喻：工程能力是核心竞争力。客户看不出淬火温度控制，但砍东西时感受得到差异。工程能力不随agent架构落伍而落伍——解决问题好、快、方便、成本低，就是工程的外化。
五阶段流水线
把模糊需求锻造成可交付产品，分五个阶段：
阶段A：需求澄清。 把模糊想法变成明确需求文档。必问五个问题：要解决什么问题、核心功能3-5项、明确不做的事、技术约束、目标用户是谁。产出 forge-brief.md。
阶段B：架构设计。 基于需求设计技术架构——模块划分、数据流、接口定义、技术栈选型与理由、任务拆解。产出 forge-design.md。展示全文给用户确认后进入下一阶段。
阶段C：审查。 独立子agent审查设计文档。核心创新：审查agent拿到的只有设计文档本身，不知道设计过程中的讨论和妥协——两个agent的盲区不重叠，对撞之后的事情一个agent单独想不到。
精审是核心竞争力——架构裂隙分析+六维度分析，逐要点三轮对撞深挖。通审收敛其余标准。最多5轮硬上限。
阶段D：TDD逐任务实现。 从设计文档的任务列表逐个实现，先写测试（正常输入、边界条件、错误输入）→确认测试失败→写实现→确认通过→重构。TDD不可跳过，顺序不可反。发现设计问题标注但不自行修改设计文档。
阶段E：归档。 记录做了什么、关键决策、遇到的问题、后续方向。产出 forge-summary.md。
分工明确：Hermes管阶段A和B（讨论需求、拆架构、写需求描述），审查和实现自动派发子agent（阶段C和D），用户做决策者（审代码、决定合并）。
架构裂隙分析：五层切口
审查阶段的核心武器。五层逐层检查设计文档，每层至少找出一个问题或确认无问题：
- 数据流——模块间数据怎么流转？有断点吗？数据契约是否清晰？
- 失败模式——每个环节可能怎么失败？有处理方案吗？错误信息能否传回上下文让模型自己读、自己分析、自己决策？
- 状态切换——系统有哪些状态？切换条件是什么？有没有非法转换路径？
- 分层检查——层间职责清晰？有跨层耦合吗？上层是否依赖了下层实现细节？
- 运维隐患——部署、日志、监控、备份、配置。上线后靠什么发现出问题了？
六维度分析：Agent工程视角
仅涉及Agent/LLM设计时启用。六个维度：
| 维度 | 检查点 | |------|--------| | 上下文工程 | 信息注入时机和分层是否正确 | | 记忆系统 | 状态持久化和跨会话记忆 | | 工具调用 | 工具定义能否让LLM正确选择 | | 可靠性 | 输出校验和重试机制 | | 成本控制 | token消耗可控性 | | 评估 | 系统是否正常工作的判断标准 |
关键是五个交叉点：上下文×成本、记忆×上下文、工具×可靠性、可靠性×评估、成本×评估。单独每维度看起来还行，交叉处最容易出裂缝。
六维度审查走三遍流程：第一遍全量代码常规审查不区分Agent/非Agent；第二遍从全量中识别Agent相关部分提取成自然语言摘要；第三遍在摘要层面做六维度精审。最终合并为统一结论。
收敛判据
审查不是无限循环。通过标准量化：
- 必须改 = 0（不改系统不可用的问题全部清零）
- 建议改不增（本轮没有新增的建议修改项）
- 自问段无新严重担忧（审查者自己重新审视结论后没有发现遗漏的严重问题）
同一问题回退——上轮改好这轮又出——立即终止，标记异常。防止在同一个坑里反复横跳。
审查报告格式
每轮审查输出标准化报告，三段式：
- 必须改：问题、位置、原因、建议
- 建议改：改了更好但不阻塞
- 可忽略：注意到了但不需要改
最后加自问段：判断有漏洞吗？过度审查吗？——审查者必须自我质疑。
前端设计教训
死亡复盘前端三次翻车，最终定位到一个系统性问题：对前端用了和后端不一样的决策方法。后端先定义本质需求再拆模块→逐层验证。前端只说"好看点""有层次感"——这些是感觉不是需求，感觉没法验证。
修正：做任何前端改动前，先回答四个问题——这个界面要让人做什么、按什么顺序、什么最重要、什么可以藏起来。回答完之前不写一行代码。
铁匠比喻的完整含义
区分真工程和工程幻象：
真工程是把问题拆成可验证的小步骤，每一步有明确的"对还是不对"标准。拆分模块让改代码更快、测试锁住已验证行为、错误处理覆盖已知失败路径。
工程幻象是没验证就设计抽象基类、为了"可扩展"加一堆没被用过的接口、在只有一个实现的情况下建工厂模式。看起来专业，实际上在替不存在的未来需求买单。
先跑通再抽离。在现有工具上验证流程，踩完坑后再抽取——不对未验证的设计做过度工程化。
