AI编程代理工程化实践：基于TDD技能套件的代码生成流程优化-程序员充电站

1. 项目概述：用技能驱动AI编程代理，实现工程化代码生成

如果你和我一样，每天都在用Claude Code、Cursor这类AI编程助手来加速开发，那你肯定也经历过那种“代码看着不错，但就是不对劲”的瞬间。AI生成的代码语法正确，逻辑清晰，但当你把它放到项目里，或者一周后想改点东西时，问题就来了：当初为什么要这么设计？这个函数到底要满足哪些边界条件？测试用例覆盖全了吗？更糟的是，AI助手自己都忘了，因为它每次对话都是“全新开始”，没有记忆，更没有流程。

这就是“无流程”开发的典型困境。AI代理默认是无状态的，它缺乏一个像资深工程师那样的、结构化的思考和工作流。它们会跳过需求澄清，直接写实现；会把测试当作可有可无的补充；会在不了解项目现状和最新API的情况下做出设计决策。最终，你得到的是“技术债”的完美雏形——一堆孤立、脆弱、难以维护的代码块。

我最近深度使用并整合了一套由Shelpuk AI Technology Consulting开源的技能套件，核心就是这个agent-skill-tdd。它的目标很明确：为AI编程代理强制注入一套完整的、基于测试驱动开发的工程化流程。根据官方数据和我的实测，这套组合拳能让AI生成的代码质量提升15-20%。这提升的不是代码风格，而是代码的可交付性、可维护性和可追溯性。简单说，它让AI像一个有纪律的工程师一样工作：先调研，再设计，测试先行，代码后置，并且每一步都有记录和审查。

这套技能不是孤立的，它和另外三个工具（Serena, Kindly Web Search, Lad MCP Server）协同工作，形成一个完整的“AI结对编程”生态系统。无论你是独立开发者想提升AI助手的产出可靠性，还是团队希望规范AI辅助编程的流程，这套方案都值得你花时间配置和尝试。接下来，我会带你完整走一遍从原理到实操的全过程，分享我踩过的坑和验证过的技巧。

2. 核心问题拆解：为什么AI需要“流程”而不仅仅是“提示”

在深入配置之前，我们必须先理解我们要解决的根本问题。很多人认为，只要给AI一个足够详细的提示（Prompt），它就能产出好代码。但现实要复杂得多。AI模型，尤其是大型语言模型，在代码生成任务上存在几个固有的、提示工程难以彻底解决的缺陷。

2.1 “无状态失忆”与上下文断裂

这是最核心的问题。当你开启一个新的会话，或者对话长度超出上下文窗口时，AI模型对之前会话中做出的所有设计决策、讨论过的边界情况、约定的API契约都一无所知。它就像一个每次见面都重置记忆的搭档。你可能会在对话中反复强调：“记住，我们用的是React 18的Hooks API，不要用Class Component。” 但几个回合后，它可能又会生成基于旧模式的代码。这种失忆导致项目知识无法积累，决策无法传承，每个功能都像是在沙滩上建城堡。

agent-skill-tdd的解法：它引入了Serena作为项目的持久化记忆体。Serena不是一个简单的聊天记录，而是一个能进行语义代码导航和记忆存储的MCP服务器。在TDD流程的“调研”阶段，AI代理会首先激活Serena，去“理解”项目的当前状态、已有的约定和记忆。设计决策、调试发现、项目惯例都会被存入Serena的记忆中，并在后续的会话中，甚至由其他团队成员发起的新会话中读取。这相当于给项目建立了一个共享的、可查询的“项目大脑”。

2.2 “静默假设”与过时知识

AI模型是基于训练数据生成内容的，而训练数据是有截止日期的。它可能“知道”某个流行库的1.0版本API，但你的项目用的是3.0版本，其中包含了破坏性变更。更常见的是，AI会基于过时的文档或它“以为”正确的模式进行设计，而不去验证。这种“静默假设”是集成错误和运行时Bug的主要来源。

agent-skill-tdd的解法：在需求澄清和设计阶段，技能会强制AI代理调用Kindly Web Search。这是一个专为获取最新API和包文档设计的MCP服务器。当AI需要确认一个函数的签名、一个库的最新用法、或一个框架的升级指南时，它会通过Kindly进行实时网络搜索，获取第一手、最新的官方信息，而不是依赖可能过时的内部知识。这确保了技术决策基于事实，而非猜测。

2.3 “自我审查”的盲区与坏令牌强化

让AI审查自己刚写的代码，效果往往有限。它容易陷入一种“自我验证”的循环，重复并强化自己生成时可能存在的模式性错误。比如，如果它在生成代码时由于某种偏好（可以理解为“坏令牌”）倾向于使用某种低效的模式，那么在自我审查时，它很可能再次认为这个模式是合理的。它缺乏一个外部的、批判性的视角。

agent-skill-tdd的解法：这就是Lad MCP Server的核心价值。Lad是一个项目感知的AI代码和设计审查工具。在TDD流程中，有两个关键节点必须经过Lad：

设计审查：在写任何代码之前，AI提出的系统设计方案必须通过Lad的system_design_review。Lad会从架构合理性、可扩展性、与现有代码库的契合度等角度提出质疑和建议。
代码审查：在TDD的“红-绿-重构”循环中，每一次小的代码变更（比如让一个测试通过）之后，都要经过Lad的code_review。这相当于每一次提交都有一次自动化的Code Review，能及时捕捉到代码风格、潜在Bug、逻辑缺陷等问题。

2.4 需求漂移与目标失焦

AI很容易在实现过程中“微调”需求，或者用它的理解覆盖你的本意，而且这个过程是静默发生的。最后代码实现了，但可能不是你想要的。因为没有成文的、双方确认的需求文档，出了问题也无法追溯。

agent-skill-tdd的解法：技能强制了一个需求先行，书面确认的流程。在动手之前，AI必须与你澄清需求，并将其结构化地写入一个永久文件：.requirements/<时间戳>_<功能名>/REQUIREMENTS.md。这个文件模板包含了“现状/目标/需求/验收标准/测试计划/实施计划”。任何需求的变更都需要重新确认和更新文档。这创建了一个不可篡改的“需求审计轨迹”。

我的实操心得：不要跳过或简化需求确认环节。即使你觉得需求很简单，也坚持让AI生成这个REQUIREMENTS.md文件。这个动作本身就是在对齐认知。我经常发现，在AI试图用文字描述验收标准时，它会暴露出对需求理解的模糊之处，这时就能提前介入修正，避免后期返工。

3. 完整工具链部署与集成指南

理解了“为什么”，我们来看“怎么做”。要让agent-skill-tdd发挥作用，你需要部署一整套工具链。这听起来复杂，但一步步来，半小时内就能搞定。我将以最常用的Claude Code和Cursor（基于Codex）为例，展示两种环境的配置。

3.1 工具链组件与角色再确认

在开始安装前，我们再明确一下这四个核心组件的关系，这有助于你理解安装顺序和配置逻辑：

组件	核心角色	安装类型	关键输出
Serena	项目记忆与导航。提供语义代码搜索和持久化记忆存储，解决“失忆”问题。	MCP 服务器	项目上下文、历史决策记忆
Kindly Web Search	实时信息核查。提供联网搜索能力，获取最新API文档，解决“过时知识”问题。	MCP 服务器	最新的官方文档片段、代码示例
Lad MCP Server	设计与代码审查。提供项目感知的AI审查，解决“自我审查盲区”问题。	MCP 服务器	设计建议、代码修改意见
`agent-skill-tdd`	流程调度引擎。定义并强制执行包含以上所有步骤的TDD工作流。	Skill (技能文件)	结构化的REQUIREMENTS.md文件、引导AI行为的指令集

它们如何协作：当你对AI说“Follow $tdd”时，tdd技能被激活。它像一位严格的教练，指导AI按顺序调用其他三个MCP服务器（Serena, Kindly, Lad）的能力，一步步完成从调研到交付的全过程。

3.2 环境一：为Cursor（或原生Codex）配置

Cursor内部集成了Codex，因此配置方法与Codex完全一致。推荐使用skill-installer进行安装，这是最简洁的方式。

步骤1：安装三个MCP服务器

你需要分别安装Serena、Kindly和Lad。它们通常通过pip安装，并需要一些简单的配置（如API密钥）。

# 1. 安装 Serena pip install serena-mcp # 安装后，通常需要设置环境变量或配置文件来指定你的Serena服务地址或API Key。 # 请参考Serena的GitHub仓库进行具体配置。 # 2. 安装 Kindly Web Search MCP Server pip install kindly-web-search-mcp-server # Kindly 可能需要配置搜索引擎API Key（如SerpAPI或Google Custom Search）。 # 运行 `kindly-web-search --help` 查看配置说明。 # 3. 安装 Lad MCP Server pip install lad-mcp-server # Lad 通常需要配置OpenAI或Anthropic的API Key以驱动其审查模型。 # 运行 `lad-mcp-server --help` 查看配置说明。

步骤2：配置Codex/Cursor以识别MCP服务器

安装完MCP服务器后，你需要告诉Codex/Cursor它们的存在。这通过在用户目录或项目目录下创建mcp.servers.json配置文件来实现。

创建全局配置文件（对所有项目生效）：

# 创建配置文件目录 mkdir -p ~/.codex

编辑~/.codex/mcp.servers.json，内容大致如下（注意：命令、参数和端口需根据你实际安装的MCP服务器文档进行调整）：

{ "mcpServers": { "serena": { "command": "serena-mcp", "args": ["--api-key", "YOUR_SERENA_API_KEY"] }, "kindly-web-search": { "command": "kindly-web-search", "args": ["--api-key", "YOUR_SERPAPI_KEY"] }, "lad": { "command": "lad-mcp-server", "args": ["--model", "claude-3-5-sonnet", "--api-key", "YOUR_ANTHROPIC_KEY"] } } }

步骤3：安装tdd技能

这是最关键的一步。我们将使用Codex内置的skill-installer系统技能来安装。

# 方法A：使用skill-installer的Python脚本（推荐，最稳定） python3 ~/.codex/skills/.system/skill-installer/scripts/install-skill-from-github.py \ --repo Shelpuk-AI-Technology-Consulting/agent-skill-tdd \ --path skills/tdd # 方法B：直接在Codex/Cursor聊天界面中使用技能指令 # 在聊天框中输入： $skill-installer install https://github.com/Shelpuk-AI-Technology-Consulting/agent-skill-tdd/tree/main/skills/tdd

安装成功后，你需要完全重启Cursor或Codex应用，以确保技能被正确加载。

步骤4：验证安装

重启后，在Cursor/Codex的聊天框中：

输入/skills或$查看已加载的技能列表，你应该能看到tdd在列。
输入What MCP servers are available?查看已连接的MCP服务器，确认serena,kindly-web-search,lad都已就绪。

踩坑记录：安装失败排查
问题：执行skill-installer命令后提示Missing --path for GitHub URL.。
原因：你使用了仓库的根URL（如https://github.com/.../agent-skill-tdd），但skill-installer需要知道技能文件在仓库中的具体路径。
解决：务必使用上面推荐的两种命令格式，它们都明确指定了--path skills/tdd或对应的分支路径。
问题：Codex报告invalid YAML: mapping values are not allowed in this context。
原因：技能文件SKILL.md的YAML头信息（frontmatter）中，description字段包含了未转义的冒号:。
解决：这是一个源仓库可能需要修复的问题。临时解决方案是，手动克隆仓库，检查skills/tdd/SKILL.md文件开头部分，确保description:后面的字符串如果包含冒号，要用引号括起来，例如description: "Enforce TDD workflow: activate..."，然后手动复制到技能目录。

3.3 环境二：为Claude Code配置

Claude Code的配置逻辑与Codex类似，但目录和技能发现机制略有不同。

步骤1：安装MCP服务器与上一节完全相同，使用pip安装serena-mcp,kindly-web-search-mcp-server,lad-mcp-server。

步骤2：配置Claude Code识别MCP服务器Claude Code的MCP服务器配置文件路径不同。

mkdir -p ~/.claude

编辑~/.claude/mcp.servers.json，内容与上一节的~/.codex/mcp.servers.json类似。

步骤3：安装tdd技能Claude Code没有内置的skill-installer，需要手动创建符号链接或复制文件。

# 创建用户全局技能目录（对所有项目生效） mkdir -p ~/.claude/skills # 方法A：创建符号链接（推荐，便于更新） ln -s /path/to/your/cloned/agent-skill-tdd-repo/skills/tdd ~/.claude/skills/tdd # 方法B：直接复制文件 cp -R /path/to/your/cloned/agent-skill-tdd-repo/skills/tdd ~/.claude/skills/

步骤4：验证安装Claude Code会在技能文件变化时自动加载。你可以直接询问AI：“What Skills are available?” 或 “What MCP servers are connected?” 来验证。

3.4 配置要点与最佳实践

API密钥管理：三个MCP服务器可能需要多个API密钥（Serena、搜索引擎、审查模型）。建议使用环境变量或安全的密钥管理工具（如direnv、1passwordCLI）来管理，不要硬编码在配置文件中。
项目级覆盖：你可以在单个项目根目录下创建.codex/skills/或.claude/skills/目录，并放置tdd技能。这样配置只对当前项目生效，适合需要不同技能组合的项目。
网络与代理：Kindly Web Search需要访问外部网络。确保你的开发环境网络通畅，如有需要，在启动MCP服务器时配置好代理环境变量。
资源消耗：同时运行多个MCP服务器和AI模型可能会消耗较多内存和API调用额度。建议根据任务需要，在mcp.servers.json中按需启用或禁用某些服务器。

4. TDD技能工作流深度解析与实战

安装配置只是开始，真正的威力在于使用。当你对AI代理说出那句“Follow $tdd”的咒语后，一个严谨的、六步走的软件工程流程便启动了。我们来一步步拆解这个流程，看看AI具体会做什么，以及你作为人类开发者应该如何与它互动。

4.1 第一步：激活与调研——建立上下文

AI行动：技能首先会指示AI代理“激活Serena”。这意味着AI会通过Serena MCP服务器，对当前代码库进行一轮语义扫描和记忆读取。它会尝试理解：

项目的整体结构和主要模块。
已有的代码风格和约定（比如，是用async/await还是Promise？）。
Serena记忆中存储的、与当前任务相关的历史决策或已知问题。

你的角色与价值：此时，AI可能会向你提问，比如“我通过Serena看到项目里有一个类似的X功能，我们这次的新功能Y和它的关系是什么？” 或者 “记忆里提到Z模块有性能问题，我们的新实现需要避开吗？”你的回答将为AI奠定正确的上下文基础，避免它重复过去的错误或与现有架构冲突。

4.2 第二步：澄清与确认需求——对齐目标

AI行动：基于初步调研，AI会开始主动向你澄清需求。它不会直接问“你要做什么？”，而是会提出一系列具体、可测试的问题，并可能根据它的理解，草拟一份初步的需求列表让你确认。例如：

“为了实现在用户仪表盘显示实时数据，我需要调用后端/api/metrics/realtime接口。这个接口的认证方式是现有的JWT吗？返回的数据格式是JSON吗？”
“‘实时’的定义是什么？是每秒自动刷新，还是用户手动点击刷新按钮？如果网络中断，UI应该如何表现？”
“这个功能需要支持移动端和桌面端吗？有现有的UI组件库可以复用吗？”

AI同时会启动Kindly Web Search，去验证它对于第三方API或库的假设。比如，它会搜索“React Chart.js latest version hook usage”，以确保它即将使用的代码模式是最新的。

你的角色与价值：这是最关键的人机交互环节。你需要像对待一位新加入团队的工程师一样，清晰、无歧义地回答这些问题。对AI的初步需求列表进行修正和补充。你的确认将作为后续所有工作的“合同”。

我的实操心得：在这个阶段，我倾向于让AI“过度沟通”。即使我觉得需求很简单，我也会鼓励它把问题问完。经常发生的情况是，它问出的某个边界条件问题，恰恰是我自己一开始没考虑到的。这本身就是一次极好的需求自查。

4.3 第三步：编写需求文档——固化契约

AI行动：在获得你的确认后，AI会在项目根目录下的.requirements/文件夹中，创建一个以时间戳和功能命名的子目录，例如.requirements/20231027T143000Z_user_dashboard_realtime/，并在其中生成一个REQUIREMENTS.md文件。

这个文件有固定的结构，是技能强制要求的模板：

As Is (现状)：描述当前系统与此功能相关的状态。
To Be (目标)：描述功能实现后，系统应达到的状态。
Requirements (需求)：分解后的、具体的功能需求列表。
Acceptance Criteria (验收标准)：可验证的、通常是端到端的验收条件。
Testing Plan (测试计划)：单元测试、集成测试、端到端测试的策略。
Implementation Plan (实施计划)：粗略的步骤划分，例如“1. 创建React组件骨架；2. 实现数据获取Hook；3. 集成图表库...”

你的角色与价值：仔细审阅这份文档。这是后续所有工作的蓝图，也是出现分歧时的仲裁依据。你可以直接在这个Markdown文件上提出修改意见，让AI更新。一旦你确认这份文档，就意味着“需求冻结”，AI将严格依此进行后续开发。

4.4 第四步：设计审查——架构把关

AI行动：在动第一行代码之前，AI会将其Implementation Plan和相关的系统设计思路，提交给Lad MCP Server进行system_design_review。Lad会像一个资深架构师一样，提出尖锐的问题：

“为什么选择引入新的X库，而不是扩展现有的Y模块？这会增加包体积。”
“你计划的数据流会与全局状态管理库Z产生冲突吗？”
“这个设计考虑了未来可能需要的A功能扩展吗？”

AI会根据Lad的反馈迭代设计，直到Lad没有更多实质性意见。

你的角色与价值：你可以旁观这场AI与AI之间的设计评审，也可以中途介入。如果Lad提出的某个问题非常重要，但AI的修改方案你不满意，你可以直接给出你的设计决策。这个步骤将大部分低级设计错误扼杀在摇篮里。

4.5 第五步：TDD循环与代码审查——步步为营

AI行动：从这里开始，进入经典的TDD小步快跑循环。AI会严格按照“红-绿-重构”的节奏进行：

红：根据Testing Plan，为一个极其细小的功能点编写一个失败的测试。
绿：编写最少量的代码让这个测试通过。
审查：立即将这一步的代码变更（可能只有几行）提交给Lad进行code_review。Lad会检查代码风格、潜在bug、逻辑错误、是否遵循了项目约定等。
重构：根据Lad的反馈和代码清洁的需要，在测试保持绿色的前提下进行重构。
循环：重复步骤1-4，直到完成Implementation Plan中的一个步骤。然后更新REQUIREMENTS.md中的进度，并进入下一个步骤的TDD循环。

你的角色与价值：你从一个“编码员”变成了一个“流程监督员”和“产品负责人”。你不需要盯着每一行代码，而是关注每个小循环后的结果：测试是否通过？Lad的审查意见是否合理并被采纳？功能是否在按REQUIREMENTS.md的定义推进？你可以在任何时候喊停，提出疑问，或调整方向。

4.6 第六步：收尾与记忆存储——知识沉淀

AI行动：当所有测试通过，功能实现完毕，AI会进行最后的整理。它会运行完整的测试套件，生成一份简短的总结。最重要的是，它会将本次开发过程中的关键设计决策、遇到的棘手问题及其解决方案、新达成的项目约定，提交给Serena，存储为项目记忆。

你的角色与价值：进行最终的验收测试。对照REQUIREMENTS.md中的Acceptance Criteria，手动或自动验证功能是否完全符合预期。确认无误后，这次开发任务才算闭环。未来，无论是你，还是你的队友，或是三个月后的AI，都可以通过Serena查询到这次开发的相关记忆，实现知识的传承。

5. 常见问题、排查技巧与效能优化

在实际使用这套工具链的过程中，你肯定会遇到各种问题。下面是我总结的一些常见故障场景、排查思路以及让整个流程更高效的心得。

5.1 安装与连接问题

问题现象	可能原因	排查步骤与解决方案
AI代理说“找不到 $tdd 技能”	1. 技能未正确安装到技能目录。 2. Codex/Claude Code未重启。 3. 技能文件`SKILL.md`格式错误。	1.检查路径：确认`skills/tdd`文件夹已正确链接或复制到`~/.codex/skills/`或`~/.claude/skills/`下。 2.重启应用：完全关闭并重新打开Cursor/Claude Code。 3.检查技能文件：打开`SKILL.md`，检查文件开头YAML部分格式是否正确，特别是`description`字段若包含冒号需用引号包裹。
AI无法调用Serena/Kindly/Lad	1. MCP服务器进程未运行。 2.`mcp.servers.json`配置错误。 3. 服务器启动失败（如API密钥错误）。	1.检查进程：在终端用 `ps aux
Kindly Web Search 返回“搜索失败”	1. 未配置有效的搜索引擎API密钥。 2. 网络连接问题或代理配置不当。	1.配置API密钥：确保按照Kindly文档配置了SerpAPI或Google Custom Search的密钥。 2.测试网络：在终端尝试`curl`一个外部网站，确认网络通畅。如需代理，在启动MCP服务器时设置`HTTP_PROXY/HTTPS_PROXY`环境变量。
Lad 审查反馈缓慢或无反馈	1. 配置的AI模型API（如Claude、GPT）调用慢或失败。 2. Lad服务器本身处理超时。	1.检查API状态：确认你的OpenAI/Anthropic账户额度充足，API密钥有效。 2.简化任务：Lad对大型代码块审查可能较慢。确保TDD循环中的代码变更足够“小”。 3.调整超时：查阅Lad文档，看是否支持配置请求超时时间。

5.2 工作流执行问题

问题现象	可能原因	排查步骤与解决方案
AI跳过了需求确认，直接开始写代码	技能未被正确触发或AI未严格遵循指令。	1.明确指令：在提示词中，将`Follow $tdd`放在最后，并且语句清晰，例如“请实现用户登录功能。Follow $tdd。” 2.中途干预：如果AI开始编码，立即打断它，重申“请先遵循TDD技能流程，从需求澄清开始”。 3.检查技能激活：输入`/skills`确认`tdd`技能处于活跃状态。
REQUIREMENTS.md 文件内容过于空泛	AI可能对需求理解不深，或你确认得太快。	在第二步（需求澄清）投入更多时间：不要满足于AI的第一版需求列表。不断追问：“还有哪些边界情况？”“非功能需求（性能、安全）是什么？”“这个验收标准是否可自动化测试？” 迫使AI思考得更全面。
TDD循环速度太慢，每个小步骤都要等Lad审查	这是为了质量牺牲速度。但对于简单或重复模式，可能显得冗余。	调整审查粒度：对于你非常有信心的、模式固定的代码（例如简单的CRUD函数），可以在AI执行几步后，手动告诉它“接下来实现X、Y、Z三个类似函数，可以作为一个步骤一起进行TDD和审查”，适当合并步骤以提升效率。
Serena 记忆似乎没有在后续任务中被用到	AI可能没有在“调研”阶段有效查询相关记忆，或记忆的存储/检索关键词不匹配。	1.明确指引：在新任务开始时，可以主动提示AI：“请先查询Serena中关于‘用户认证’和‘API错误处理’的记忆。” 2.优化记忆内容：在任务结束时，审阅AI准备存入Serena的记忆，确保其描述准确并包含了关键术语，便于未来检索。

5.3 效能优化与高级技巧

定制你的需求模板：如果你觉得默认的REQUIREMENTS.md模板不适合你的团队，你可以修改skills/tdd/SKILL.md文件（对于手动安装的副本），调整其中关于生成需求文档的指令部分，加入你们团队特定的章节，如“数据库变更计划”、“回滚方案”等。
分层使用技能：不是每个任务都需要完整的六步流程。对于修复一个明确的bug，你可以指示AI：“使用Serena定位问题，然后Follow $tdd进行修复。” 对于代码重构，你可以强调：“重点使用Lad进行设计审查和代码审查，Follow $tdd。” 通过上下文提示，让AI聚焦在流程中最有价值的环节。
管理AI的“固执”：有时AI和Lad会在某个设计或代码细节上陷入无意义的争论。如果你认为Lad的建议不适用，或者AI的理解有偏差，要果断行使“人类仲裁权”。直接给出明确的指令，例如：“采用方案A，忽略Lad关于X的建议，原因是Y。” 记住，你始终是项目的最终决策者。
成本与速度的平衡：频繁调用Lad（使用Claude/GPT模型）和Kindly（网络搜索）会产生API费用和耗时。对于个人项目或原型阶段，你可能希望节奏更快。可以考虑：
- 在mcp.servers.json中临时注释掉lad和kindly-web-search的配置，仅在需要时启用。
- 使用更轻量、快速的模型（如果Lad支持配置）进行代码审查。
- 对于非常确定、无需搜索验证的知识，在需求澄清阶段直接告诉AI：“关于Z库的使用，请直接使用最新稳定版API，无需搜索确认。”
将流程融入团队：这套工具链非常适合团队共享。将配置好的.codex或.claude目录、mcp.servers.json范例以及一份简明的使用指南纳入团队的知识库。统一的需求文档格式（REQUIREMENTS.md）和项目记忆（Serena）能极大提升团队的协作效率和知识留存度。

这套agent-skill-tdd及其工具链，本质上是在用工程化的方法论来“规训”AI的创造力。它不替代你的思考，而是将你的思考过程结构化、显式化、可追溯化。最初的几天你可能会觉得流程繁琐，但一旦适应，你会发现它带来的代码质量提升、决策可追溯性和团队协作的顺畅感，远超过那一点点额外的时间开销。它让AI编程从一种“神奇的对话”，变成了一种可靠、可重复、可协作的工程实践。