Introducing tacit-skills - an AI coding harness

tacit-skills 是我在实践了好几个月的 AI Coding 之后，修修补补加改改最终落地的一套解决方案。

如果你已经读了项目的 Readme: 那我建议你可以拿一个小的需求，哪怕是一个编程题来测试一下; 如果没有，那容我简答自卖自夸一下:

本来的命名是 YYDS-skills — [Y]et another [Y]ou [D]on’t [S]ay ：）

tacit 是一套给 coding agent 用的 harness，除了一些 skills，最重要的是开发过程中的几个 SOP。
不是为了用 skill 而用 skill，而是把一些重复性的劳动、提示词和工程模板内化到不同的 skill 里，并让模型自行路由到不同的 SOP。

遇到的问题

从 copilot 的自动提示开始，到 cursor 的侧边栏聊天式开发，再到现在的 cli 开发 (codex/claude code)，AI 遇到的是和人类开发者一样的问题。

你怎么连话都说不清楚
你怎么连话都听不清楚

但聪明的 AI 不会跟你争辩，只会一味的输出，最后还要被开发者喷 - 这个模型幻觉好严重。事实是 ~~你跺你也麻~~ 人一样会遇到这些问题。所以我们有需求评审、需求澄清、一轮轮的和产品策划沟通细节，落文档，直到开始编码。

所以在这个过程中，人类开发者需要扮演的角色是，以开发人员的视角，将收到的信息处理、整合，并分享给 Code Agent，阅读 Agent 的反馈，最终做决定。
在这个过程中，代码本身的重要性逐渐降低，而文档(或者说，类文档的产物)的重要性逐步提升。它们能够保证让你在与其他人类开发者，或者其他 Agent 沟通时消弭障碍(前提是，Ta们真的能读懂)。

此外，还有一些常见的拖慢开发进度的情形:

新功能的一句话需求
新功能的设计完全不考虑历史实现，或者接手一个新坑
需求/架构/依赖中途改了
项目约定变了，别人的 Agent 还按上个月的习惯写
验过一轮之后踩过的坑，下次又遇到
口口相传的"最佳实践"

怎么解决

随便挑几个痛点来解释我怎么做。

一句话需求

己所不欲，勿施于人。开发最烦一句话需求，那就不要给 AI 一句话需求。开发在现在 AI 强辅助之下主要承担的工作，应该是把需求的复杂度摊开，技术的复杂度交由AI负责，而业务的复杂度则由开发者自己承担。因此 blueprint 作为每个新需求的入口，需要你提供足够多的信息，同时 Agent 也会借此来拷问你，直到 Ta 能够解决问题。

历史包袱

tacit 里有多个分析工具，用来读你的历史代码，让他知道哪里是已有的技术债，哪里是新挖的坑。新挖的坑，你找时间填上，技术债且如果是 约定俗成 就还是要遵循。

输出的文档

前面提到了，我认为 文档 的重要性会逐步大于代码，因此，每个阶段产出的文档需要符合一些软性的规范。其中也不乏参照了一些我认为的最佳实践。

上下文

历史、上下文、记忆、convention，不管是哪种讲法，都是 “提供给模型用于思考的历史内容”。如果配置了 honcho memory，那么将补齐全部的上下文板块。
session中有当前对话的上下文，memory/ledger 提供关于需求/代码库的上下文，honcho 包含全局的开发习惯和实践，而其他可复用的文档例如 prds/plans 则包含了 Agent 解决问题过程中的上下文。包含以上上下文信息，相信大部分 Agent 结合合格的模型，都可以有不错的效果。

里面有什么

一切以仓库下的 README.md 为准

最开始的版本一共包含 16 个独立 skill，按阶段大致是：

上手 & 维护

warmup — 根据仓库进行初始化分析，产出当前仓库的开发习惯和约定
scout — 对照约定查哪里有 smell code 或者漂移(drift, 不符合开发约定的地方)
charter — 把你批准的漂移写回项目记忆
code-analyze — 代码分析，可以按照需要的维度进行分析

设计 & 实现

blueprint — 对话中澄清需求，产出实现计划
builder — 按计划把功能做出来
pivot — 需求有变动或理解有偏差：改 PRD、记 delta、把旧产物标 stale

验证 & 善后

bailiff — 规格驱动验证 + 契约级检查 <- CR大师
plumb — 检查 feature 的 plan/build/verdict 过期了
inquest — 作为 bailiff 配套的 “验尸官”，检查问题是否真的存在，并进行修复
distill — 事后复盘，把 bailiff 报告收敛成踩坑合集

汇报 & 杂项

herald — 把 markdown 报告渲成可分享的 HTML (experimental)
json-to-schema — 样例 JSON → draft-07 schema
以及一组 honcho-* 长期记忆（可选装）

典型主线大概是：

warmup → blueprint → builder → bailiff
         （scout / charter 在变更落地后）
         （pivot / plumb 在需求发生变化时）
         （inquest 在实现跟计划对不上时）
         （distill 在循环之外做阶段性复盘）

blueprint / builder / bailiff 之间靠 context ledger 递上下文，保证连贯性。

写在后面

我始终认为 Harness 只是模型能力还不够(超级)强的时候的过渡方案，甚至我认为是用来约束开发者自己不要滥用 AI Agent。
目前已经可以看到 Anthropic 的 SoTA 模型内化了很多 harness 能力，很难说有一天 harness 会变成拖累模型发挥的凶手。
但在此之前，还是希望我的这套东西能用、有用、好用。

再次，introducing tacit-skills.