你要的不是“工具组合”而是开发操作系统。结论先说Obsidian 管知识Harness 管约束Trae 管执行Git/CI 管交付。你现在最容易犯的错误是以为把几个 AI 工具串起来就能自动完成开发。错。真正能跑通的是这条链需求 → 规范 → 任务拆解 → AI 编码 → 人审查 → 自动验证 → 部署 → 复盘沉淀一、三者分工1. Obsidian项目大脑Obsidian 不要拿来乱记笔记。它应该是你的产品与技术知识库。里面只放这些核心内容/00-项目总览 /01-需求池 /02-业务流程 /03-数据库设计 /04-接口设计 /05-前端页面 /06-后端服务 /07-规则与约束 /08-问题复盘 /09-AI提示词模板你的 Obsidian 负责回答这个系统要解决什么问题 有哪些角色 有哪些页面 有哪些接口 有哪些数据库表 哪些规则不能违反 以前踩过什么坑不要把它变成“资料垃圾场”。如果一条笔记不能指导开发、测试、排错、决策就别放进去。2. Harness开发约束层这里我按你之前说的agent harness / 约束工程来理解不是单纯 Harness.io CI/CD 平台。Harness 的本质不是“生成提示词”而是把 AI 的行为限制在一个可控、可验证、可复盘的工程框架里。这个方向和近期 agent harness 的定义一致harness 负责让模型看到项目、调用工具、接收反馈并判断改动是否完成相关研究也把它拆成任务规格、上下文选择、工具访问、项目记忆、验证、权限、失败归因、审计等职责。(arXiv)你应该在代码仓库里建这个目录/harness project.md # 项目总说明 architecture.md # 架构约束 coding-rules.md # 编码规范 db-rules.md # 数据库规则 api-rules.md # 接口规则 frontend-rules.md # 前端规则 backend-rules.md # 后端规则 task-template.md # 任务模板 done-definition.md # 完成标准 review-checklist.md # 审查清单 bug-fix-template.md # Bug 修复模板GitHub 上的 agent-harness 示例也是类似思路用原则、清单、提示词、invariants/guardrails 做 AI 辅助开发治理层而不是随口给 AI 一段话。(GitHub)3. Trae执行层Trae 不应该负责“想清楚产品”。它应该负责读需求 读 Harness 约束 分析代码 生成实现计划 改代码 跑测试 解释改动 协助修 bugTrae 官方对 SOLO 的定位就是你定义任务、审核结果AI 规划开发流程、使用工具、执行并交付代码。(TRAE)所以 Trae 的正确用法不是“帮我做一个系统”。正确用法是“基于这些文档和约束完成这个小任务。”二、完整开发链条你应该这样跑Obsidian 写需求 ↓ 整理成 Harness 任务卡 ↓ 复制任务卡给 Trae ↓ Trae 读代码 读约束 实现 ↓ 本地运行 / 单元测试 / 接口测试 ↓ Git 提交 ↓ CI/CD 构建部署 ↓ Bug / 经验回写 Obsidian 和 Harness如果你用的是 Harness.io 平台它可以放在 CI/CD 层。Harness 官方文档覆盖 Code Repository、Continuous Integration、Continuous Delivery GitOps、Feature Flags、SAST/SCA、Supply Chain Security 等模块适合做构建、测试、部署、发布控制。(Harness开发者中心)三、你应该采用的目录结构你的 Java Vue 项目建议这样改project-root /backend /frontend /docs /product /api /db /workflow /harness project.md architecture.md coding-rules.md db-rules.md api-rules.md task-template.md done-definition.md review-checklist.md /tests README.mdObsidian 里维护知识。代码仓库里维护 Harness。两者不要完全分离否则 AI 每次都拿不到最新约束。建议做法Obsidian 长期知识库 Git /harness 当前项目可执行规则四、Harness 文件怎么写project.md# 项目说明 ## 项目目标 本系统用于企业评估报告自动核查、目录抽取、附件一致性校验、OCR 识别、规则判断和结果输出。 ## 技术栈 - 后端Java Spring Boot - 前端Vue - 数据库MySQL / MongoDB / Redis - 文件阿里云 OSS - AI 工作流Dify / OCR / LLM ## 核心模块 1. 报告上传 2. PDF 转图片 3. 目录抽取 4. 附件核查 5. 规则判断 6. JSON 合并 7. 报告导出coding-rules.md# 编码规则 ## Java 规则 - Controller 只做参数接收和返回不写业务逻辑。 - Service 负责业务编排。 - Mapper 只负责数据库访问。 - 所有外部接口调用必须有异常处理。 - Redis key 必须集中定义不允许散落硬编码。 - 涉及并发任务时必须说明线程池、超时、异常合并策略。 ## 禁止事项 - 禁止在 Controller 中直接写 SQL。 - 禁止吞异常。 - 禁止返回 null 作为业务结果。 - 禁止没有日志的 catch。done-definition.md# 完成标准 一个任务完成必须满足 1. 代码可以编译通过。 2. 核心逻辑有测试或可验证步骤。 3. 不破坏已有接口。 4. 不引入重复代码。 5. 异常路径已处理。 6. 日志足够排查问题。 7. 已说明改动文件和影响范围。 8. 已说明如何回滚。task-template.md# 任务卡 ## 背景 说明为什么要做这个功能。 ## 目标 明确最终要实现什么。 ## 输入 列出接口参数、文件、数据库字段、前端入口。 ## 输出 列出返回结果、页面效果、JSON 格式或数据库变化。 ## 约束 列出不能破坏的规则。 ## 涉及文件 列出可能修改的后端、前端、SQL、配置文件。 ## 验收标准 列出如何判断做完。五、给 Trae 的标准提示词你以后不要再这样问帮我做这个功能这太粗。AI 会乱发挥。你应该这样给 Trae你现在作为本项目的开发 Agent。 请先阅读 1. /harness/project.md 2. /harness/architecture.md 3. /harness/coding-rules.md 4. /harness/done-definition.md 5. 当前任务卡 任务 【这里粘贴任务卡】 要求 1. 先分析涉及哪些文件不要直接改代码。 2. 给出实现方案。 3. 标明风险点。 4. 等我确认后再改代码。 5. 修改后说明 - 改了哪些文件 - 为什么这样改 - 如何测试 - 是否影响旧功能如果是修 Bug用这个你现在负责修复一个已有 Bug。 请先做四件事 1. 复现问题路径。 2. 找到最可能的根因。 3. 列出涉及文件。 4. 给出最小修改方案。 Bug 现象 【粘贴错误日志 / 截图 / 代码】 约束 - 不允许大改架构。 - 不允许绕过异常。 - 不允许删除已有业务规则。 - 优先最小改动。六、推荐工作流阶段 1需求进入 Obsidian你在 Obsidian 写# 功能评估报告附件核查 ## 用户目标 上传评估报告后系统自动判断附件是否完整。 ## 核查项 - 营业执照 - 承诺函 - 备案公告 - 评估师登记卡 - 审计报告 ## 输出格式 { 营业执照: [], 承诺函: [], 备案公告: [] }阶段 2转成 Harness 任务卡# 任务实现附件核查 JSON 合并逻辑 ## 背景 多个 AI 节点会返回不同附件核查结果需要统一合并。 ## 目标 同 key 合并数组索引取最靠前非 0 值。 ## 输入 多个 JSON 对象。 ## 输出 合并后的 JSON。 ## 约束 - 空正文返回空数组。 - arg3false 返回空对象。 - 同 key 值拼接。 - 索引取最靠前非 0。 ## 验收标准 给定 3 组 JSON输出结果符合规则。阶段 3交给 Trae 执行Trae 负责找代码、改逻辑、生成测试。你负责审查它有没有破坏规则。阶段 4结果回写做完之后把经验写回/08-问题复盘/JSON合并规则.md /harness/db-rules.md /harness/api-rules.md否则你每次都重新解释一遍AI 永远不会变聪明。问题不是 AI 笨是你的上下文系统没有积累。七、最小可执行版本你别一开始搞复杂。先做这 5 个文件/harness/project.md /harness/coding-rules.md /harness/task-template.md /harness/done-definition.md /harness/review-checklist.md然后每个功能都按这个流程1. Obsidian 写清楚需求 2. 复制到 task-template.md 3. 让 Trae 先分析不准直接改 4. 确认方案 5. 让 Trae 改代码 6. 运行测试 7. 把坑写回 Obsidian 和 Harness这就够你跑完整链条。八、你真正需要改的地方你现在的问题大概率不是工具少而是需求、规则、代码、测试、复盘都散着。散着的结果就是AI 每次都像新员工 你每次都重新解释 代码越改越乱 Bug 越修越多 知识无法复用正确目标是让 AI 每次进入项目时都能读到同一套项目规则。 让每个任务都有明确输入、输出、约束、验收标准。 让每次 Bug 都沉淀成下一次的防错规则。一句话Obsidian 是你的长期记忆Harness 是 AI 的行为边界Trae 是执行工人。你要做的是设计流水线不是迷信工具。