摘要AI 编程助手的瓶颈不只在模型能力更在工作流约束。本文基于 nine arm skills 的设计思想解析 Debug、Review、Postmortem、Management Talk 等技能如何提升智能体在真实工程场景中的可靠性并给出可落地的 Python API 调用示例。背景介绍AI Coding 不缺能力缺工程纪律过去一年AI Coding 工具快速演进Claude Code、Cursor、Codex、Verdant 等工具不断增强模型能力、上下文窗口、工具调用和代码编辑能力。很多团队在使用 AI Agent 修复 Bug、生成测试、重构代码时会自然地把优化方向放在“更强模型、更大上下文、更多工具”上。但实际工程中一个常见问题是AI Agent 往往过早行动。例如开发者贴出一段错误日志后Agent 立即判断“问题已找到”随后修改多个文件错误变化后又继续修改更多文件。最终表面上看 Agent 一直在工作实际上它可能只是在追逐症状而不是基于可复现路径定位根因。nine arm skills 的价值就在于它不是一个庞大的 AI 编程框架也不是新的 IDE而是一组面向 Agent 行为的工程化约束模板。它强调智能体表现不仅取决于模型智能也取决于工作流智能。核心原理把“工程纪律”注入 Agent 行为nine arm skills 中比较核心的可用技能包括Debug Mantra调试规则系统Postmortem工程复盘模板Scrutinize代码审查约束Management Talk面向管理层的技术沟通转换这些技能不是简单 Prompt而是对真实研发流程中失败模式的抽象。1. Debug Mantra修复前必须先复现Debug Mantra 的核心原则是在提出修复方案之前必须完成四个步骤可靠复现问题明确失败路径主动质疑假设将每次运行结果作为证据链这解决了 AI Coding 中最常见的问题Agent 在没有理解失败机制前就开始写代码。一个更健康的调试 Agent 不应该直接回答“我会修改这里”而应先输出复现命令是什么当前失败现象是什么失败路径经过哪些函数、文件、模块当前假设是什么如何证伪这个假设下一步最小验证动作是什么这相当于在 Agent 的行动链路中加入“必要阻力”。它会让 Agent 在修复前变慢但最终修复会更干净、更可靠。2. Postmortem拒绝“看似专业的废话”大模型非常擅长生成结构完整、语气专业的文档但这也带来一个风险它可能把猜测包装成 RCARoot Cause Analysis根因分析。Postmortem 技能强调如果缺少必要事实就停止撰写复盘。必要事实包括是否有可靠复现步骤根因是否明确修复方案是否确定修复是否经过验证哪些测试通过哪些文件和函数发生了变化为什么原有流程未能提前发现问题这类复盘不是给管理层看的摘要而是给未来工程师使用的事故记录。文件路径、函数名、测试命令、验证结果都必须具体。3. Scrutinize审查不能由实现者自证代码审查 Agent 的重点不是“确认代码看起来不错”而是从冷启动视角审视最终 diff是否引入新的边界条件问题是否破坏已有行为测试是否覆盖真实失败路径修复是否过度设计是否存在隐藏副作用视频中提到一个关键思想实现 Agent 刚写完代码很难客观审查自己的结果。因此审查 Agent 应与实现 Agent 分离最好运行在隔离工作区中。一个 Agent 构建一个 Agent 测试一个 Agent 审查一个 Agent 输出最终记录这才是接近真实研发组织的智能体协同工作流。4. Management Talk技术事实与业务表达分离调试日志不是复盘复盘也不是领导层更新。Management Talk 的作用是把技术记录转换成适合业务沟通的内容例如Slack 更新站会摘要Jira 进展说明面向管理层的风险说明它不应该篡改技术事实而是基于 Postmortem 中已经验证的信息转换表达粒度。例如把“auth/session.py中 token refresh 分支缺少异常处理”转换为“登录会话在特定过期场景下会失败已修复并补充回归测试”。工具选型多模型 Agent 工作流的统一接入在搭建 AI Coding Agent 工作流时我更关注三点API 稳定性、模型更新速度、多模型切换成本。我个人常用的 AI 开发平台是薛定猫AIxuedingmao.com。它采用 OpenAI 兼容接口适合在工程项目中快速接入不同大模型。平台聚合了 500 主流大模型包括 GPT-5.4、Claude 4.6、Gemini 3.1 Pro 等新模型通常能较快上线开发者可以第一时间通过 API 体验前沿模型能力。对于多 Agent 场景统一接口可以显著降低接入复杂度调试 Agent、审查 Agent、复盘 Agent 可以复用同一套调用封装仅通过模型名或系统提示词区分角色。下面示例默认使用claude-opus-4-6。这是 Claude 系列中面向复杂推理、代码理解、长链路任务表现较强的模型适合代码审查、根因分析、工程文档生成等需要严谨推理的场景。实战演示用 Python 构建一个 Debug Mantra Agent下面代码演示如何通过 OpenAI 兼容 API构建一个遵循 Debug Mantra 的调试助手。它不会直接给出修复代码而是先要求模型输出复现、失败路径、假设和验证计划。使用前请将XUEDINGMAO_API_KEY设置为你的 API Key。importosfromopenaiimportOpenAIclassDebugMantraAgent: Debug Mantra Agent 目标 1. 不在缺少复现信息时直接修复代码 2. 强制输出失败路径、假设、证伪方法和下一步验证动作 3. 将每次执行结果沉淀为调试证据链 def__init__(self,api_key:str,model:strclaude-opus-4-6):self.clientOpenAI(api_keyapi_key,base_urlhttps://xuedingmao.com/v1)self.modelmodeldefanalyze_bug(self,bug_report:str,code_context:str)-str:system_prompt 你是一个严谨的 AI 调试代理必须遵循 Debug Mantra 1. 在没有可靠复现步骤前不允许提出最终修复方案。 2. 必须先识别失败路径包括相关文件、函数、调用链和输入条件。 3. 必须列出当前假设并说明如何证伪每个假设。 4. 必须把每次运行、日志、错误变化视为 breadcrumb证据线索。 5. 如果信息不足明确指出缺失信息并给出最小补充请求。 6. 输出应面向工程师避免空泛结论。 请按以下结构输出 - 问题摘要 - 当前可确认事实 - 缺失信息 - 最小复现计划 - 失败路径分析 - 待验证假设 - 证伪策略 - 下一步建议命令 - 是否允许进入修复阶段是/否并说明原因 user_promptf 请分析以下 Bug 报告和代码上下文。 【Bug 报告】{bug_report}【代码上下文】{code_contextifcode_contextelse暂无额外代码上下文}responseself.client.chat.completions.create(modelself.model,temperature0.2,messages[{role:system,content:system_prompt.strip()},{role:user,content:user_prompt.strip()}])returnresponse.choices[0].message.contentif__name____main__:api_keyos.getenv(XUEDINGMAO_API_KEY)ifnotapi_key:raiseRuntimeError(请先设置环境变量 XUEDINGMAO_API_KEY)bug_report 线上登录接口偶发 500。 错误日志 TypeError: cannot unpack non-iterable NoneType object 位置auth/service.py:87 用户反馈刷新页面后偶尔恢复。 code_context # auth/service.py def get_user_session(token): if not token: return None session query_session_from_cache(token) if session: return session.user_id, session.expired_at # fallback to database db_session query_session_from_db(token) if db_session and db_session.is_active: return db_session.user_id, db_session.expired_at return None def login_required(request): user_id, expired_at get_user_session(request.headers.get(Authorization)) if expired_at now(): raise UnauthorizedError(session expired) return user_id agentDebugMantraAgent(api_keyapi_key)resultagent.analyze_bug(bug_report,code_context)print(result)这段代码的关键点不在于“让模型修 Bug”而是通过系统提示词限制 Agent 的行为边界没有复现不进入修复没有根因不写结论没有验证不输出确定性复盘。工作流设计四类 Agent 分工协作在真实项目中可以将 nine arm skills 的思想扩展为四类子代理Debugger Agent负责复现问题、收集日志、定位失败路径、维护调试证据链。Implementation Agent在根因明确后进行最小化修复避免无关重构和大范围修改。Reviewer Agent独立审查最终 diff重点关注边界条件、回归风险、测试覆盖和副作用。Postmortem / Comms Agent在验证通过后生成工程复盘并进一步转换为团队更新、站会摘要或管理层说明。这一流程的核心是“分离”实现不是审查调试日志不是复盘复盘也不是管理层更新。每个产物都有自己的职责每个 Agent 也应有清晰边界。注意事项不要把所有技能塞给所有任务在设计 AI Coding 工作流时需要避免几个误区不要让 Agent 过早修复修复动作必须建立在可靠复现和明确失败路径之上。不要让实现 Agent 自我审查审查应由独立上下文的 Agent 完成降低确认偏误。不要用 AI 生成伪 RCA缺少事实时应让模型明确停止而不是补全想象。不要混淆受众工程复盘需要技术细节管理层更新需要风险、影响和进展。不要一次加载所有技能正确做法是在合适阶段启用合适行为。例如调试阶段启用 Debug Mantra验证通过后再启用 Postmortem。总结nine arm skills 的启发在于提升 AI Agent 的工程表现不一定要继续堆叠模型、工具和上下文。有时更高杠杆的方式是为 Agent 设置正确的行为约束。让 Agent 在容易冲动修改代码的地方慢下来在适合并行的环节并行起来这才是 AI Coding 从“单点问答”走向“工程协作系统”的关键。#AI #大模型 #Python #机器学习 #技术实战
