面向技术负责人的 AI 工程治理方法论
AI 引入后，代码一致性开始下降，团队难以维持统一的工程标准。
Review 成本上升，因为需要识别生成代码背后的隐含假设与边界。
技术债风险加剧，局部最优的实现堆叠成系统性失控。
当约束缺失时，架构、质量与维护性都会被动下滑。
本项目不是教写代码，而是防止工程失控。
技术负责人需要把注意力放在规则、边界与审计机制上。
核心目标是让 AI 在可验证的约束中执行。
- 输出必须结构化（结构化测试模板/Schema/Checklist）
- 规则优先，自然语言提示被约束
- 人只审规则，AI 执行
我们从测试环节开始，因为：
- 测试是最容易量化的质量指标
- 测试工作流能验证“结构化约束”的有效性
- 有了测试，才敢放心让 AI 大规模生成代码
但这只是第一步，完整的 AI 编程工作流还包括： 需求澄清 → 架构设计 → 代码实现 → 测试验证 → 代码审查
当前实现方式（基于 api-test skill）：
- 分析代码路径（Controller/Service）
- 直接生成 REST Assured 测试类 + SQL fixture
- 执行测试
- 报告结果
现有的 2 个 skills（结构化约束的具体应用）：
-
api-test：生成并执行 REST Assured + JUnit 5 API 测试- 生成测试类、fixtures 和断言
- 自动处理认证、数据准备、执行与结果报告
- 支持 Docker 容器化测试（默认）和本地模式
- 基于真实 API 响应进行探测验证
-
test-fixture：管理测试数据- 创建或更新 SQL fixture
- 支持单库、跨库数据关联与验证码登录场景
为什么这样设计：
- 模板可审查：团队能 review 测试模板和生成规则
- Fixture 可复用：同一份 SQL fixture 支持多个测试场景
- 探测优先：基于真实 API 行为而非代码推测
# 1. 配置项目约定（模板：project-conventions.yaml）
# 2. 创建测试数据 fixture
/test-fixture 用户登录场景
# 3. 生成并执行 API 测试
/api-test POST /api/users/login假设场景：POST /api/users/login
1) Fixture SQL
-- 幂等：先删后插
DELETE FROM users WHERE id = 900001;
INSERT INTO users (id, email, password_hash, status)
VALUES (900001, 'test@example.com', 'hashed_password', 'ACTIVE');2) 生成的测试代码（REST Assured）
given()
.contentType("application/json")
.body(payload)
.when()
.post("/api/users/login")
.then()
.statusCode(200)
.body("token", notNullValue())
.body("user.id", instanceOf(Integer.class));3) 测试结果（示例输出）
[PASS] user login - status 200
[PASS] user login - token exists
[PASS] user login - user.id is number
注意：这里的断言来自结构化测试模板，而不是 AI “猜测”出来的逻辑。
- 当前：Java/Spring Boot + REST Assured
- 计划：Python/FastAPI、Node.js/Express...
痛点：产品说“做个用户系统”，AI 不知道要做到什么程度 方案：结构化需求模板（功能清单、边界条件、验收标准）
痛点：AI 不理解系统全局，容易产生碎片化方案 方案：架构约束文档（模块划分、接口规范、技术栈限制）
痛点：每个人用 AI 的方式不同，代码风格千奇百怪 方案：编码规范 + Prompt 模板库
痛点：AI 生成的代码缺少测试，边界情况没覆盖 方案：结构化测试工作流（当前 2 个 skills）
痛点：Review 成本高，因为要理解 AI 的逻辑 方案：自动化 Checklist + 关键决策标注
痛点：缺少变更记录，出问题难以回溯 方案：自动生成变更摘要和 Rollback 计划
如果你也是技术负责人，在探索 AI 编程的落地方案：
- 有哪些环节最头疼？
- 有哪些约束机制有效？
- 团队规模和技术栈是什么？
欢迎分享你的实践和踩过的坑。
讨论渠道：
- Issues：问题反馈和需求讨论
- Discussions：经验分享和最佳实践
贡献指南：
目录：poc/claude-agent-sdk/
研究目标：探索 Claude Agent SDK 作为 AI 编程工作流执行引擎的可行性
核心发现：
- ✅ Claude Agent SDK 可作为轻量级 AI 助手（如 nanobot）的执行引擎
- ✅ 自定义 Agents 功能支持任务路由和角色专业化
- ✅ 完整的工具生态（Read/Write/Bash/Edit + MCP 协议）
- ✅ 成本可控（Haiku $0.11, Sonnet $0.20-0.44 per query）
测试覆盖：
- 基础查询和工具使用
- 多轮交互式对话
- MCP 工具集成（自定义工具 + 内置工具）
- 自定义 Agents（code-reviewer, tester, refactorer 等）
生成代码质量：
- fibonacci.py：3 种实现方式，完整类型提示和文档
- test_fibonacci.py：60+ 测试用例，覆盖边界条件和性能测试
详细文档：
- POC_SUMMARY.md - 整体测试总结
- AGENTS_SUMMARY.md - Agents 功能深度分析
应用场景：
- 作为 nanobot 等轻量级 AI 助手的调度层
- 多渠道接入（Telegram/Feishu/WhatsApp）的统一执行引擎
- 与 Codex 等 MCP servers 集成进行代码实现
我们在独立实践项目 ~/git_home/lucy-code 中，将本方法论落实为可运行系统：
- 显式状态机驱动任务闭环：
NEW -> CLARIFYING -> WAIT_APPROVAL -> RUNNING -> TESTING -> DONE/FAILED - 飞书接入 + OpenCode 执行 + 任务级 worktree 隔离
- 结构化日志、任务事件与测试报告沉淀，支持审计与复盘
这说明本项目的方法论不仅可写成文档，也可映射到真实工程实现。
详细展示见：