这两年我大部分精力都花在一件事上让 AI Coding 在企业真实的研发节奏里真正跑通。单机玩 AI Coding 的时候提示词写得好坏还能靠手感补但一旦放到几十人、上百人协作的代码库上最大的瓶颈根本不是模型聪明不聪明而是你用什么结构去约束它、引导它、验收它。这一点就是所有做 AI Coding 平台和工具链的人反复提到的 Harness而真正让它落到每个具体工程任务上的抓手是一层层可组合的 Skill。我最早接触这个思路是在评估不同代码助手的扩展机制时发现各家都在收口到一个相似结论与其让一个全能 Agent 自由发挥不如在它外面包一套可控的 harness把需求理解、架构设计、任务拆解、编码实现、代码评审、测试门禁、安全扫描、发布复盘这些环节分别做成独立 Skill再串成一条全链路。这篇文章就基于我自己的实战经验把这套东西拆开讲清楚包括 Skill 的标准结构、8 个 Skill 怎么分工、怎么接入现有仓库、以及实际跑链路时最容易翻车的几个坑。不管你是正在做企业级 AI 编码平台的工程师还是想给自己团队搭一套编码 Agent 体系的负责人都可以拿这套思路直接去改、去落地。1. Harness 到底是什么Skill 在中间扮演什么角色1.1 从我踩过的第一个坑说起早年间做 AI 编程助手我最朴素的做法是拉一个上下文窗口很大的模型把整个仓库喂进去然后让它写代码。效果看起来不错demo 也能惊艳全场。可一到真实项目就露馅仓库稍大一点上下文烧得飞快模型写到一个文件的时候经常忘了另外几个模块的接口约束更麻烦的是它经常“自信地”修改了不该改的业务代码而且没人知道它为什么改、改了什么、改了之后影响面多大。后来我意识到纯粹让模型“自由发挥”根本不适合工程场景。我们可以把模型想象成一个能力很强但纪律性很差的实习生。你直接把一整个仓库丢给他让他自己看自己写他大概率会东一榔头西一棒槌。正确的办法是给他一张严格的工作台规定好他现在只能看哪几个文件、使用哪几个命令、按照哪份规范输出做完一步必须停下来给你检查。这张“工作台”就是 Harness。1.2 Harness 工程的五个组成部分我实际落地时会刻意把 harness 拆成五个模块来设计对应一句话就是模型在什么边界内、以什么顺序、调用什么工具、遵循什么规范、产出什么产物。编排控制层Orchestrator决定当前走哪个流程阶段比如先做需求分析再做技术方案再进入编码每一阶段的入口和出口都有明确状态。上下文管理层Context Engine决定把仓库的哪些文件、哪些文档片段送给模型什么时候做检索、什么时候做摘要压缩避免上下文无限膨胀。工具网关层Tool Gateway统一收口模型能执行的命令与工具例如读文件、写文件、跑测试、查代码、调用静态扫描器每一项都有权限边界和白名单。规则与护栏层Policy Guardrails写死一些不可触犯的红线比如不允许改动锁定目录、不允许绕过评审直接合并、不允许把密钥写入代码。记录与评测层Telemetry Eval把每次任务输入、每一步动作、模型使用了哪些 Skill、最终产物是什么全部记录方便回放和评测。其中 Skill 属于“能力包”挂在编排控制层之下。我在项目里给它的定义是一组解决特定问题的提示模板、脚本、规则参数和产出模板的集合能够在特定阶段被加载、被触发、被评估。它和“让 Agent 自己规划每一步”最大的区别在于Skill 是有边界的、可复用的、带验收标准的。1.3 Skill 和 Agent 有什么区别很多人会把 Skill 和 Agent 混为一谈这个必须掰扯清楚。Agent 是一个自主决策体它会根据目标自己决定下一步调用什么、看什么、写什么。Skill 则更像“技能卡”它是被更上层编排逻辑按需调用的单元。假设我们要写一个支付回调接口用纯 Agent 的方式模型会自己决定先读代码还是先写接口用 Harness Skill 的方式流程是固定的先触发需求 Skill 产出验收清单再触发架构 Skill 确定接入点然后才轮到编码 Skill 在受限目录里动手。Agent 适合探索型、开放式任务Skill 适合重复度高、流程明确、有质量预期的工程任务。企业级场景里我更推荐“有 Agent 能力但用 Skill 管理关键节点”的混合模式整体流程可以用编排器串联每个具体阶段才引入对应 Skill全部动作都在工具网关和规则护栏的控制内。这样做的好处是风险可控出了问题可以精准定位到某个 Skill 而不是一整个黑盒 Agent。2. 为什么是 8 个 Skill全链路拆解与编排思路2.1 企业级 AI Coding 的全链路应该长什么样我在规划企业级 AI Coding 能力时不会一上来就写编码 Skill而是先把软件交付生命周期走一遍找哪些环节 AI 能稳定产出价值。跑了很多真实项目之后我总结出最适合 AI 介入但必须人工盯住产出的八个环节对应下面的链路需求入口 → 需求澄清与验收标准定义 → 技术方案设计 → 任务拆解与排期 → 编码实现 → 代码评审与修复 → 测试生成与质量门禁 → 依赖与安全审查 → 发布说明与复盘归档。请注意这里的“需求入口”不是指 AI 自己拍脑袋想需求而是接收产品经理写的用户故事或 issue这条链路的终点也不是代码合并就结束而是形成可回溯、可维护的知识资产。企业里最怕出现的情况是AI 把代码写出来了但没人知道这段代码为什么这么写、验收点是什么、出了线上事故回滚依据在哪。2.2 8 个 Skill 的分工原则顺着上面的链路我设计了 8 个 Skill按序覆盖全流程。每个 Skill 都遵守几条硬原则单一职责每个 Skill 只解决一个阶段的问题不越界。需求 Skill 绝不写代码编码 Skill 绝不替团队做架构决策。显式输入输出每个 Skill 都声明需要外部提供什么内容以及必须产出什么格式的产物。比如需求 Skill 的产物是一份带验收标准的 PRD 文档。可测试性每个 Skill 都附带一组样例输入和期望输出模型改动或者提示词调整后能跑一次回归。可观测性Skill 内部动作会被记录成结构化日志包括触发原因、读取的上下文片段、调用的工具、产出文件路径。在这套原则下编码 Skill 只是 8 个中的一个而不是全部。很多时候 AI Coding 效果不稳定不是因为编码环节不行而是前序的需求理解、任务拆解没做好导致模型在错误的上下文里写不对代码。这就像一个施工队图纸都没画清楚就开始砌墙墙砌得再快也是歪的。2.3 链路编排里的“人机节点”全链路串起来不等于全自动化。我在每一个环节之间都设置了人机检查点受控的自动化才能长时间稳定运行。以实际落地为例链路只在少数几个节点支持全自动执行比如测试生成、安全扫描脚本的运行、发布说明草稿生成其余节点如架构方案选型、关键代码评审结论必须有人确认后再放行到下一阶段。这张“什么地方让 AI 全自动、什么地方留给人拍板”的清单我通常会写成一个 gate-config 配置文件放在仓库根目录作为 Harness 读取的第一份策略文件。gate-config.yml requirement: human_review design: human_review plan: auto code: sandbox review: human_review test: auto security: auto_block release_note: auto看到这里你应该能理解为什么我在开头强调这不是单机写代码的游戏。单机场景下你不需要 gate、不需要 Skill 编排但企业级场景任何一个环节的失控都可能放大成全团队事故。3. Skill 的最小工程实现Manifest、上下文与工具3.1 一个 Skill 的标准结构我在自己的仓库里采用了一个通用目录规范兼容目前主流的 Skill 生态写法。每个 Skill 以独立目录形式存在目录下必须有 SKILL.md 元信息文件其余文件按需组织。结构如下.harness/skills/ └── requirement-parse/ ├── SKILL.md ├── prompt.tmpl ├── scripts/ │ ├── extract_acceptance.py │ └── validate_prd.py ├── templates/ │ └── prd.md ├── rules/ │ └── requirements_quality_rules.md └── tests/ ├── sample_issue_1.md └── expected_output_1.mdSKILL.md 是核心承担注册和触发判断的作用。下面是我在实际项目中使用的精简版name: requirement-parse description: 将原始 issue 或一句话需求扩展为结构化 PRD 与可测试验收标准 version: 1.4.0 trigger: type: issue_label label: skill:requirement fallback_prompt: #需求解析 input: required: - issue_title - issue_description output: files: - path: docs/prd/{issue_id}.md template: templates/prd.md permissions: tools: [read_repo, git_log, read_template, write_docs] allow_paths: [docs/**] deny_paths: [src/**]metadata 里的 permissions 非常关键它规定了 Skill 的工具权限和路径边界。你在企业里部署时一定不要给所有 Skill 统一授予写代码的权限而是按最小权限原则拆分。比如 requirement-parse 只能读仓库和写 docs 目录连 src 目录都不允许碰。这样即便模型后续行为出现了偏差它也没有能力把改动扩散到业务代码里。3.2 Skill 的加载与调度机制Harness 启动后会扫描 .harness/skills 下所有 Skill 目录把 SKILL.md 中声明的元信息注册进一个技能注册表。当一条新的任务进来编排器会先做触发判断如果用户显式指定了requirement-parse或者 Issue 带有对应标签就加载该 Skill如果没有显式指定则根据输入内容与 description 的语义相似度做匹配。这个匹配逻辑要做得保守一些宁可匹配不上也不要错误触发避免模型在一个需求任务里突然跑去执行安全扫描。下面是调度逻辑的简化示意我在本地调试时用它验证触发链路是否正常# harness_router.py async def route(session): active [] for skill in skill_registry.values(): if not skill.enabled: continue if await skill.should_activate(session): active.append(skill) if len(active) 1: return active[0] if len(active) 1: # 多 Skill 命中时优先显式标签其次按分数 return max(active, keylambda s: s.match_score) return fallback_skill我见过不少人把 Harness 调度写成“把仓库全量文件交给模型让它自由判断”那是偷懒的做法。正确的做法是把上下文获取也放进 Skill 内部让每个 Skill 自己声明需要什么语料再由 Harness 的 Context Engine 按需检索。编码 Skill 需要代码结构地图和调用链分析需求 Skill 只需要最近的提交历史加上相关目录的 README这两者需要的上下文侧重点完全不同。3.3 Skill 上下文管理的两个经验上下文膨胀是我在真实项目里遇到最频繁的问题。模型输出质量下降往往不是模型退化了而是它被迫处理了大量无关上下文。为此我做了两件事。第一给每个 Skill 挂载“上下文最小集”声明在 SKILL.md 里用 context 字段声明需求的文档和代码范围。第二对超长上下文做分段摘要比如让模型先读仓库目录树和关键文件头部注释再进行针对性检索而不是一次性灌入大文件。context: mode: selective include: - docs/prd/{issue_id}.md - docs/decisions/** use_tools: - repo_map - symbol_search max_tokens: 12000第二个经验是 Skill 的输出必须落在文件里而不是只停留在对话流。对话很容易丢只有把每个 Skill 的产物实体化成 PRD、ADR、任务清单、评审报告等文件后面的环节才有据可依。比如架构设计 Skill 结束后编码 Skill 再去读的就不是模型聊天记录而是 docs/decisions 下的结构化技术决策文档。4. 8 个 Skill 逐个拆解与实战参数4.1 Skill 01需求澄清与验收标准定义这个 Skill 位于链路最前端很多人会忽略它的价值但它直接决定了后续七个 Skill 有没有谱。我设计的 requirement-parse Skill 要做三件事把原始 issue 里的模糊表述转换成明确可执行的任务描述识别缺失的业务规则和边界条件把不可测试的描述改写成带 Given-When-Then 结构的验收标准。输入实例通常是一条一句话需求比如来自用户的 issue。我举一个实际处理过的例子“用户希望在订单列表页增加按金额筛选功能”。这句话如果不加澄清直接交给编码 Agent很可能出现三种完全不同的实现前端只做本地过滤、后端接口新增分页参数、或者两者兼做。requirement-parse 在读取仓库中订单模块的代码后会产出一份包含以下内容的 PRD筛选字段类型与精度、金额单位与币种、筛选与现有搜索条件的关系、空结果态、权限约束、埋点事件名等。这个 Skill 内部还有一套质量自检规则我放在 rules 目录下例如任何结果字段必须带类型定义、任何交互动作必须描述错误分支、禁止出现“等等”“相关”这类不可验收的词。产出后还会运行 scripts/validate_prd.py 做一次格式校验不合格就直接返回补充要求不让模糊需求流到下一关。4.2 Skill 02架构设计与技术选型需求澄清完成后进入架构设计 Skill。我把它命名为 arch-design但它的产出不是一张 PPT而是一份轻量级 ADR架构决策记录。ADR 的价值在于记录“为什么”而不只是“做了什么”。比如团队在对一个接口方案做选择时harness 会结合现有仓库结构给出一份备选方案对比包括侵入范围、兼容性、测试成本三列打分然后由人来确认最终选型。在企业级代码库里我不想让 AI 自己去“发明”一个异于团队习惯的架构。所以在 arch-design 的 rules 文件里我会显式写入仓库现有的分层规范和技术栈约束模型建议方案时必须先考虑复用已有组件。这个 Skill 的触发条件通常是需求 PRD 评审通过后由上一环节标记为 ready-for-design而不是等开发时才临时抱佛脚。架构 Skill 的典型产物文件放在 docs/decisions 下文件名包含日期和场景。我用下面的模板做骨架# ADR-20260828-订单筛选方案 ## 状态 proposed / accepted ## 背景 来自 PRD 的原始诉求由 requirement-parse 产出 ## 决策 选择方案 B后端分页 前端筛选面板 ## 备选方案对比 - 方案 A纯前端过滤适合数据量 100 条 - 方案 B后端条件查询适合数据量大且需深链分享 - 方案 C独立搜索服务成本高暂不采用 ## 影响 - 修改 order_query API - 影响面订单列表页、订单导出功能 - 适配改造量需新增查询参数与索引这个文件会在后续编码 Skill 被加载时作为上下文模型就能明确知道自己为什么采用某个写法不会出现代码实现与设计意图背离的问题。4.3 Skill 03任务拆解与开发计划生成拿到 ADR 之后planning Skill 负责把设计决策拆成可执行的任务单元。这个环节对编码 Agent 至关重要。我的切身体会是让一个 Agent 一次性写一百个文件几乎必然失控把它拆成每次只改一个功能点、一个模块、带一个验收命令的小任务成功率会大幅提升。planning Skill 会输出一个 tsconfig 风格的任务清单但字段是针对 AI 执行优化过的。每个任务单元至少包含任务编号依赖的前置任务涉及变更的文件列表期望的代码行为以及一个可执行的验证命令。我通常让模型把仓库中相关的类型定义、接口签名、数据库迁移文件提前列出来并在拆解时标注阻塞关系。这样可以避免两个任务并行执行时发生文件冲突。生产环境里我还给任务拆解加了一个约束单个任务不允许横跨三层架构一个任务只能改动接口层、业务层、数据层中的一层。如果模型觉得某个需求需要同时改三层那就说明拆解得还不够细需要继续拆。这个规则极大降低了 AI 编码时“把层与层之间的边界搅乱”的风险。4.4 Skill 04编码实现主执行单元终于到了大家最关心的 coding Skill。我这里的做法可能和你在网上看到的“一句提示词生成整个项目”不太一样coding Skill 是严格按照上游 planning Skill 的任务清单逐个执行的一个任务单元跑完且验证通过后才会申请执行下一个任务单元。每个任务单元执行时模型只把相关文件拖进上下文而不是整个仓库。coding Skill 的具体工作流大概是读取任务清单中指定文件的最新代码 → 读取项目风格指南中对应语言的规范片段 → 按需求生成差分修改建议 → 由 harness 把改动应用到工作区 → 运行该任务单元配套的验证命令 → 如果失败将错误信息作为反馈回到模型继续修复。这里我强烈建议在所有编码类 Skill 上启用“沙箱模式”或“建议模式”让模型不直接改文件而是产出带文件路径和 diff 的建议经过工具网关校验路径合法后再合并。这样既能避免模型误改不属于本任务的模块又能保留完整的审计日志。一个实际的技巧是在 prompt.tmpl 里明确要求编码 Skill “不要同时处理多个问题”。很多编码质量下降都源于模型一口气修了三个问题结果相互影响。我通常会把一个任务单元的目标限定为一个行为变更任何超出范围的修改都要显式报告给编排器由人工决定是否扩展。4.5 Skill 05代码评审与整改建议代码完成合并之前review Skill 需要像一个挑剔的 senior engineer 那样过一遍变更。这个 Skill 会读取本次改动的完整 diff结合仓库内预先配置的编码规范、禁用 API 清单和历史常见 bug 模式输出一个结构化的评审报告。评审维度我固定为四类正确性风险、安全隐患、性能隐患、可维护性问题每个问题必须标注文件行号、严重级别和修改建议。很多人问过我怎么让 review Skill 的结论可信。我的经验是给它喂三样东西第一仓库自带的 git log 中历史 review 意见让它学习团队的关注点第二一份团队内维护的“常见缺陷清单”markdown 文件第三改动文件对应的单元测试结果。有了这三样review 才不会泛泛而谈“建议增加注释”这种废话。review Skill 产出的意见我设计成两级blocker 级别意见会直接导致本任务重新回到 coding Skill 修复suggestion 级别意见则聚合后在每周评审会上由人来决定。团队如果完全信任模型评审也不现实所以我设置了一个“AI review 通过率”指标定期抽检。只要人为发现 AI review 漏掉了引入线上问题的严重 bug该 Skill 的权重和版本就需要回炉优化。4.6 Skill 06测试生成与质量门禁代码评审通过后质量测试这一环节也不应该完全靠开发手写。quality-gate Skill 会根据本次改动和代码覆盖情况自动生成需要的单测与集成测试补充。它并不是盲目生成一堆覆盖率报告就结束而是先做差异分析本次改动涉及哪些核心业务分支现有测试是否覆盖未覆盖分支的风险等级有多高。生成测试时我通常要求模型遵循团队既有测试框架的风格并且测试断言必须基于业务行为而不是实现细节。例如针对订单筛选接口应该断言“amount 大于 filter_value 的记录不返回”而不是断言“调用了某个内部方法”。这能避免模型生成一堆测试实现绑死的脆弱用例。在质量门禁上我会让 quality-gate Skill 执行一条预置命令序列lint → 类型检查 → 单测 → 覆盖率汇总。任何一步失败都像上游抛异常一样把失败原因精准塞回开发阶段。测试是这个链路里少有的几个可以全自动执行的卡点因为命令结果是客观的模型没有辩论空间这恰好是企业 AI Coding 需要的确定性。4.7 Skill 07依赖、密钥与注入面安全扫描security-scan Skill 在 CI 或预合并阶段运行负责四类扫描依赖组件漏洞核对、密钥与敏感信息泄漏扫描、AI 生成代码中可能存在的注入与权限绕过模式、以及对本次 diff 提出安全评审意见。这个环节要注意的是它不是一个独立的“全代码库漏扫”而是针对本次 AI 变更链路做增量安全审查范围更聚焦、噪音更小。实际操作中我让 security-scan Skill 复用已有的开源扫描工具把扫描结果解析成结构化报告再让模型针对扫描结果做一次语义分析。比如某个依赖版本报出 CVE单纯靠工具无法判断这个漏洞是否被当前代码路径真正利用模型可以结合本次 diff 是否触及相关 API 来做判断。它得到的结论是“本次不构成可利用路径建议下个迭代升级”还是“当前代码直接调用了受影响方法必须阻止合并”差异很大。这个 Skill 有一个我很看重的保护机制一旦报告里出现任何密钥泄漏或高危急漏洞harness 会直接进入 block 状态禁止后续任何自动化流程继续并把相关责任人拉进来。不要小看这一步很多团队把 AI 编码接入 git 后第一次事故往往不是代码写错而是模型在测试代码里顺手硬编码了一把密钥。4.8 Skill 08发布说明、回滚预案与归档复盘最后一个 Skill 经常被省略但它决定了整个 AI Coding 链路能否长期留在企业里。release-doc Skill 负责在合并后自动生成发布说明、回滚预案和归档复盘文档。它会读取本次合并涉及的任务清单、ADR、评审报告及测试结果自动生成面向业务的发布摘要和面向研发的变更详情。回滚预案不是一句“回滚上个版本”那么简单。我会让模型结合 ADR 中描述的数据库迁移动作识别哪些变更无法简单通过回滚代码解决。比如某次改动新增了非空数据库字段并且做了数据回填那么回滚代码的同时必须配套执行逆向数据脚本这个提示会在 runbook 里用单独高亮列出。模型还会基于线上监控指标模板指出应该重点观察的指标例如订单接口筛选功能对应的 p99 延迟和错误率。最后一个动作是写归档复盘纪要内容包括本次 AI 编码任务中哪些 Skill 表现稳定、哪些环节中途返工、哪些 prompt 引发了误解。这些纪要文档又会沉淀为规则库的知识来源作用于下一次迭代的 Skill 优化。全链路跑了几轮之后这个回流机制的价值会越来越大。5. 真实仓库接入 Harness 的方法与工具选型5.1 工具底座怎么选关于 Harness 的具体实现业内没有统一标准我做选型时主要看三个分层模型入口、能力底座、代码平台。模型入口现在可选择的范围非常大包括各类闭源和开源模型以及面向国内环境和本地部署的 DeepSeek 系列模型。在企业数据合规要求下不少团队会把模型私有化部署harness 服务与模型服务之间走标准接口。能力底座建议优先选择支持插件或 Skill 机制的编码代理框架这样可以省去很多底层工作把精力集中在规则配置上。在代码平台侧GitLab 或 GitHub 的 MR 能力和 Webhook 几乎是标配Harness 的编排服务和代码平台通过事件驱动集成。整个链路我用一张事件表来管理触发事件调用 Skill完成产物放行条件issue 创建requirement-parsePRD 文档人工评审通过PRD 评审通过arch-designADR 文档架构师确认ADR acceptedplanning任务清单自动放行任务单元就绪coding代码 diff单测通过MR 发起review评审报告无 blocker评审通过quality-gate测试补充测试通过代码合入前security-scan安全报告无高危建议合并完成release-doc发布说明与回滚预案自动归档不要试图一次把这张表全部打通我建议按模块灰度推进。先从 requirement-parse 和 release-doc 这种低风险环节入手它们不会直接修改生产代码能让团队先建立对 AI 产物的信任感再逐步开放 review 和 quality-gate 的自动执行最后才把 coding Skill 放到可写沙箱里。在很多团队里一上来就开放编码权限是推进失败最快的方式。5.2 接入仓库的最小操作步骤下面给出我实际落地的接入顺序照着做基本能避掉大部分雷在仓库根目录创建 .harness 目录包括 skills、policies 和 gate-config.yml。从需求解析 Skill 开始先将 SKILL.md 放到 .harness/skills/requirement-parse 目录做一次样例 issue 的 dry-run 验证。配置 Harness 服务的触发源把 issue 标签 skill:requirement 注册为触发事件。让模型读取仓库的 README 与关键模块头注生成 repo-map并缓存成文件供后续 Skill 使用。每成功稳定一个环节再增量添加下一个 Skill在 gate-config.yml 中打开对应开关。人工评审小组抽查每个 Skill 的产出报告反馈问题后迭代相关 Skill 的 rules。实际接入时我建议给每个 Skill 配一个冒烟测试集。所谓冒烟测试就是准备一组典型的输入样例比如库存模块订单筛选的 issue、认证模块权限变更的 issue观察 Skill 输出是否符合预期。任何 prompt 模板升级之后先跑这套冒烟测试再上线到真实任务。别迷信大模型“这次一定行”Skill 是工程产物版本迭代必须有回归手段。5.3 版本管理与多人协作Harness 和 Skill 本质上都是代码资产一定要纳入 Git 管理而不是散落在某个服务器目录里。我习惯在独立仓库维护 skills然后以子模块或者包形式挂到各业务仓库。Skill 版本的变更要走和业务代码一样的评审流程升级日志要记录在 CHANGELOG 中避免某次 Skill 规则更新后所有业务仓库行为被悄悄改变而没有人察觉。这里要特别注意一个协调问题业务代码仓库经常存在多分支并行开发同一个 Skill 升级后在不同分支跑出来的产物可能不一致。所以我在 CI 层面固化 Skill 版本每次任务开始前记录 skill_version将其写入任务 trace 日志。这样出问题时能精确定位“任务 A 是用 requirement-parse 1.3.0 跑的任务 B 是用 1.4.0 跑的”而不是拿着不同版本的产物互相比较。这个细节在多人协作时非常重要。6. 常见问题与排障实录6.1 上下文膨胀导致模型“越改越乱”现象是模型刚开始写第一两个任务时状态很好到第三个任务开始遗忘前序决策甚至重复引入已经被否决的实现方案。排查逻辑很简单查看 trace 日志中每轮任务的 token 消耗曲线如果发现每轮都把完整对话历史传给模型说明是上下文膨胀。我的解决办法是引入中间态归档每个任务单元执行完毕后把该单元的结论压缩成一段“已确认事实”文件后续任务只读取这份文件不再回放完整对话历史。实践下来模型的长任务保持率提升明显而且每次任务的输入 token 消耗也能控制在稳定水平。记住一句话对话历史是负担产物文件才是上下文。6.2 Skill 误触发或编排顺序被打乱我在调试中遇到过几次类似“明明在写需求 PRD结果模型跑去调用代码评审”的情况。根因通常是 trigger 判断逻辑太宽松或者是某个 Skill 的 description 里关键词覆盖太广导致语义匹配误伤。建议的排查顺序是先看路由日志确认该任务命中了哪个 Skill 以及匹配分数是多少再检查被误触发的 Skill 的触发条件是否需要收紧。我更推荐用“显式标签为主、语义匹配兜底”的策略业务侧提需求时必须打上 skill:xxx 标签语义匹配只在标签缺失且系统有高度把握时才启用。这样编排顺序不会跑偏每个环节的负责人也能预期下一个环节是什么。你甚至可以加一道“任务前置卡片”检查也就是当前 Skill 在没有找到上游产物文件时主动拒绝执行而不是自己脑补补全。6.3 Skill 改了但效果变差怎么办Skill 迭代和模型升级一样存在回归风险。有一次我把 coding Skill 的详细度要求提高后生成代码的防御性确实变强了但同时也把简单的接口实现写得异常臃肿。如果没有回归手段这种变化会随着每个任务悄悄腐蚀代码库。我目前的做法是把每组 Skill 冒烟测试的结果指标化编码任务通过率、评审 blocker 数量、每千行缺陷率、上下文 token 消耗量等。Skill 版本升级时对比这些指标波动过大就回滚或调整 prompt。另一点经验是不要指望一个 prompt 全能你宁可把规则分散成多个小的 policy 文件让每个文件只覆盖一个方面比如 defensive-coding-policy.md、logging-policy.md、error-handling-policy.md这样定位问题时只需要改其中一个文件不用把整份大 prompt 推倒重来。还有一类问题需要特别留意模型本身更新也可能导致 Skill 输出风格骤变。所以完善的 harness 一定要保留 skill_version 和 model_version 的双重记录。看到这里你应该能理解为什么我会说企业级 AI Coding 的护城河不是某个惊艳的模型而是这套能持续观测、迭代、回滚的 harness 工程体系。7. 这 8 个 Skill 落地之后我的一点真实体会如果让我用一句话概括这套 8 Skill 全链路的本质我会说它不是为了让 AI 更像一个全知全能的人而是为了让 AI 成为企业里一个边界清晰、动作规范、产出可验收的工程单元。每个 Skill 都像一个专业的工种harness 是工地的管理制度模型是高效率的执行者三者配合才不会把施工现场变成无人驾驶的灾难片。我自己从最早的单会话写代码到现在把 8 个 Skill 跑进多个真实仓库最大的变化不是代码生成速度而是“返工成本”在体系化下降。以前模型写完代码靠人肉 review 发现问题常常是推翻重来现在每个环节都有前置产物和验收阀错误被压在更早的阶段暴露修复半径小得多。当然这套体系也不是一步到位的最开始只需要在一个仓库里把需求解析和发布归档两个低风险 Skill 跑熟团队的信心建立起来以后再逐步把编码、评审、安全这样的重环节放进流程里节奏反而更快。最后再分享一个小技巧每个 Skill 的负责人要明确。我见过不少团队把 Skill 当成纯提示词文档谁都能改最后规则自相矛盾模型行为像抽风。后来我们给每个 Skill 指定了 owner改规则必须带着测试记录在评审会上过一遍。这个工程管理上的小动作比调十版 prompt 都管用。AI Coding 的 Harness 工程说到底还是一门关于约束与信任的工程。