用 TRAE 从零做一个 AI 个人工作台
我给自己排活，这几年一直是同一个样子：周一早上列 12 条，周五剩 7 条，月底换一张新清单，旧的直接消失。没有哪一条被问过，为什么没做。
也不是没试过工具。备忘录、表格、待办 App 都用过，最后都变成一个只记「欠」、不记「还」的本子：任务写进去了，完成没有定义，做完没有验收，没做完也没有原因。清单越换越新，问题一直没动。
今天就围绕这个麻烦，用 TRAE 做一个 AI 个人工作台。它要解决的问题很窄：打开就能看见今天该干哪三件，提交成果后按事先写好的标准判一次，没做完的必须留下原因。
先说清楚，它比上一个选题管理工具重：有数据库、有状态机，还要调模型。所以第一版只做地基，四个 sprint 分开做，这篇讲的是第一版怎么开工。
第一步：先把第一版的范围划清楚
如果我直接告诉 TRAE「帮我做一个个人工作台」，它得替我们猜一堆事：给一个人用还是团队用？要不要登录？要不要接日历？要不要自动排期？猜得越多，做出来的东西越像一个漂亮空壳：页面都在，点进去没有数据。
先给它一个明确的定位：这是一个给一个人用的、在电脑浏览器里打开的工作台，每天只回答两个问题。
- 今天该干哪一件？
- 这一件算不算干完了？
第一版只做五件事：
- 建任务，每条必须带完成定义
- 首页显示今日焦点，最多三条
- 看板能看到全部任务和状态
- 提交成果，AI 按完成定义逐条判
- 每次改动写一条变更日志
这次不做：登录、团队协作、手机端、日历同步、自动抓取任务、多 Agent 协作，这六件事都不做。
有人会问：待办 App 和表格也能记任务，为什么还要自己做一个？
能记，但记的不是一回事。待办记的是「要做什么」，这个工具记的是「做完没有、为什么没做」。前者是清单，后者要留证据：完成定义、交付物、审核结论、变更记录。表格能存这些字段，但存不了「提交之后必须判一次」这个动作。
第二步：每条任务必须带「完成定义」
一条任务要记什么？我建议第一版只留八样：标题、为什么做、完成定义、交付物类型、类型、估时、状态、计划日期。
标题写成动宾短语，一眼知道要做什么。为什么做只写一句，说清它挂在哪个目标上。完成定义是三到五条能判真假的判据。交付物类型只能从文件、链接、一句话结论、沟通记录里挑一个。类型分产出型和推进型，产出型有东西交，推进型只有过程。估时以半天为单位。状态按下一步的固定路径走。计划日期想不好就先空着，不要瞎填。
这里面有一条不能省：完成定义。
光写「把方案写一下」，这条任务永远停在「差不多了」，既不能算完成，也没法取消。补上判据，它才动得起来。
举三个例子就明白了。「质量要好」判不了，改成「含 3 个客户案例，每个写清行业和规模」就能判。「研究一下竞品」判不了，改成「列出 5 家竞品，每家一句差异结论」。「跟进客户」判不了，改成「有一次沟通记录，写明对方下一步动作和时间」。
判断标准很简单：这条能不能用「是」或「否」回答。答不了，就还不是完成定义。
估时也要落到半天。写「大概两三天」，排期的时候没法算容量；写「1.5 个半天」，加起来才能和这周的可支配时间比。
第三步：打开 TRAE，先立规矩，不要先写代码
新建一个空文件夹，比如 workbench，用 TRAE 打开。
先别急着让它写页面。这个项目有三条约束，只要有一条被破，后面全乱：状态只能按固定路径改、AI 只能写提议不能写任务、表结构不能随手动。这些约束写在对话里，聊几轮就丢了，所以要先写进项目规则。
TRAE 的项目规则放在 .trae/rules/ 目录下，可以设置四种生效方式：始终生效、指定文件生效、智能生效、手动触发（对话里用 #Rule 引用）。规则文件多了，可以建子目录分类，最多三层。
我把它拆成六份：
- 00-总则.md，始终生效，压在 60 行内，写技术栈、目录、命名和禁改清单。
- 10-数据模型.md，始终生效，50 行内，写表和状态枚举，改表必须先问。
- 20-API契约.md，指定文件生效，只匹配 app/api/**，70 行内，写路由、入参出参和错误码。
- 30-UI规范.md，指定文件生效，匹配 app/** 和 components/**，70 行内，写布局、空态、加载态、失败态。
- 40-AI层.md，指定文件生效，匹配 lib/ai/**，90 行内，写上下文规则、输出格式和提示词路径。
- 50-验收.md，手动触发，40 行内，写验收命令、什么算完成、什么必须停下来问。
为什么要拆，而不是写一篇长提示词？两个原因。
一是一条规则塞太多东西，约束会互相打架。TRAE 官方的最佳实践里也写了：单条规则要聚焦，规则之间不能冲突。二是长文件读到后面，前面的约束容易被忽略，最后丢的往往是最关键的那条。
00-总则里的硬规则，我建议这么写：
---
alwaysApply: true
---
# 项目总则
## 技术栈（不许替换）
Next.js + TypeScript + Tailwind + Node 24 内置 node:sqlite。
不许新增任何依赖，需要时先在对话里说明理由等我批准。
## 目录
页面只放 app/，业务逻辑放 lib/domain/，AI 调用放 lib/ai/。
## 禁改
db/schema.sql 改表结构必须先问我
lib/ai/skills/*.md 提示词由我维护，你只能读
data/ 运行时数据，不许写死路径
## 硬规则
1. 一次只改一个功能，不许顺便优化别的地方。
2. 任何状态变更必须走 lib/domain/task-state.ts，不许直接改 status。
3. AI 层只能写 proposal、submission、review，不许写 task。
4. 写完后必须跑 node scripts/verify.mjs <sprint>，并贴出原始输出。
每条约束后面最好带一句为什么。「不许新增依赖」后面补上「需要时先说明理由等我批准」，它才不会把这句当成建议。
规则建好，第一段话这样发给它：
请先读一遍 .trae/rules 下的六份规则，不要写代码。
读完之后只做一件事：用三句话复述这个项目的三条禁令，
以及你这一轮不允许修改的目录。
我确认后你再开始。
它如果直接动手，说明规则没生效，先停下来检查规则的生效方式，别急着往下走。
第四步：让它先出规格，不要先出页面
很多人用 AI 编程，第一句话是「帮我实现一个工作台」。这样得到的东西通常能跑，但不能用：字段少了、状态乱了、验收标准是它自己编的。
所以这一轮只让它写文档。四个 sprint，每个 sprint 四份：
- S1 地基：建表、今日焦点、看板、任务增删改、变更日志。验收是建 10 条任务，关掉重开还在，非法状态改不动。
- S2 对话：上下文组装、三个线程、拆解、提案卡、批准落库。验收是一句模糊需求，出 8 条以内带完成定义的提案，批准后才进看板。
- S3 审核：提交表单、逐条对照、状态机。验收是有缺口的交付物被判打回，且状态没被审核器改掉。
- S4 周计划：复盘聚合、容量闸、临时任务重排。验收是承诺总量不超过容量，插临时任务只能选三个方案。
第一张规格卡这样发：
这一轮只写 specs/01-foundation 下的四份文档，不写代码。
01-需求.md：这个 sprint 做什么、不做什么、3 到 5 条验收标准。
02-拆解.md：功能清单 F1 到 F5，每个功能的输入输出契约。
03-数据.md：涉及的表、字段、索引，给出建表语句。
04-测试.md：验收用例，用 Given / When / Then 写。
约束：
验收标准必须是能用「是」或「否」判断的句子，
不许出现「体验良好」「基本可用」。
做完把四份文件列出来，等我确认。
写完别只看它「产出齐全」，要自己读一遍，重点看三处：
- 有没有擅自加上登录和多用户？
- 有没有漏掉变更日志？没有它，后面复盘没有数据。
- 04-测试.md 里的用例，能不能真的跑？「页面正常显示」不算用例，「建 10 条任务，直连数据库查到 10 行」才算。
这三处现在改，只动几句话；等页面写完再改，要动一堆文件。
第五步：第一张卡只做建表和今日焦点
规格确认了，再开始写。第一张卡只做两件事：建表，和今日焦点页。
本轮只做 specs/01-foundation 里的 F1 建表和 F2 今日焦点页。
先复述这两项的验收标准，等我确认后再写代码。
允许修改：db/schema.sql、app/(workbench)/today/、lib/domain/focus.ts。
其他文件只读。
三条禁令：
1. 不新增依赖。
2. 不改表结构，需要改先问我。
3. 不跨目录改文件。
做完跑 node scripts/verify.mjs 01，把原始输出贴给我。
哪条验收做不到，停下来告诉我哪条、为什么，
不要绕过，也不要改验收标准。
这里有两个细节值得说。
一是「先复述，再动手」。它复述得不对，说明规格有歧义，这时候改文档比改代码便宜。
二是「一次只给一个功能的上下文」。四份规格可以全带上，但让它一口气把 F1 到 F5 都做了，出来一定是一层空壳，点进去什么都没有。
第六步：验收交给脚本，不交给「它说完成了」
AI 编程工具最会改的东西，不是代码，是验收标准。你说「提交后状态要变成待审核」，它为了省事，可能把这条写成「状态可以变成待审核」，然后告诉你已通过测试。
所以验收要写成脚本，跑出来的结果才算数。
请写 scripts/verify.mjs，只做 S1 的验收，不依赖模型 API。
必须覆盖：
1. 通过接口建 10 条任务，直连 sqlite 查到 10 行。
2. 非法状态迁移返回 409，库里状态不变。
3. 删掉一条任务后，变更日志多出一条，actor 正确。
4. 服务没启动时，标注 SKIP，不要报通过。
每条失败都要打印具体缺什么。
另外给建表文件和提示词加一把锁：把 sha256 写进一个文件，verify 每次比对。它偷偷改表或者放宽提示词，脚本直接红。只有我自己跑 node scripts/hash-lock.mjs 才解锁。
这一步听起来麻烦，但它挡的是最贵的一类问题：你以为改的是代码，其实改的是标准。
第七步：用一周真实任务试一遍
页面能打开，只说明它有个界面。拿这一周真实的活当测试数据，先建十条，再一条一条试下面八种情况。
- 建任务时不写完成定义，保存要被拒，并提示至少 3 条判据。
- 提交一个空交付物，审核结论是打回，并写出缺的是哪一条。
- 审核打回之后，任务要回到进行中，不是已完成。
- 直接把状态从「待办」改成「已完成」，接口拒绝，状态不变。
- 删掉一条任务，要有二次确认，删完变更日志多一条。
- 把 30 小时的活塞进 20 小时的周计划，冻结要被拒，并提示超了多少。
- 关掉浏览器和终端再重新打开，十条任务都还在。
- 插一条临时任务，只给三个方案，没有「直接加进来」。
提醒：做审核测试时，先用一条测试任务，别拿正在推进的活直接试。AI 判错很正常，第一周打回率偏高也不是坏事。
上面是验收标准，不代表这些功能已经通过测试。 实操时哪项过了、哪项出错，就记哪项。
数据保存在哪，也要说清楚。
第一版把数据存在项目目录下的一个 SQLite 文件里，不上云、不登录。同一台电脑、同一个目录，重新打开能读到；换电脑、换目录、删掉这个文件，就读不到了。重要任务定期把文件复制一份出去，客户资料和账号密码别往里放。
还有一个坑值得提前说：项目如果放在中文路径下，better-sqlite3 这类需要编译的库很可能装不上，报错是 node-gyp 编译失败，同一份代码放到纯英文路径就正常。这种报错 AI 也看不懂，会让它绕很久。换成 Node 24 内置的 node:sqlite，整个项目没有原生模块，中文路径照跑。
第八步：用起来以后，再决定加什么
等建任务、提交、审核、变更日志都跑顺了，再调字体、间距和颜色。
之后加什么，看用起来卡在哪，不要提前加。
- 老是排超 → 先做容量闸，不要先做甘特图
- 打回率一直是 0 → 先检查完成定义是不是写得太松
- 真需要在手机上记一条 → 再讨论账号和同步
- 开始存项目复盘、想按意思搜 → 再考虑上向量库
第一版不要上向量库，也不要上多 Agent。任务库几百条，全量注入也就几千 token，装得下；三份提示词是三次独立调用，输入输出都定死了，不需要协商。这两样东西加早了，换来的只有延迟翻倍和更多 bug。
这次练手最值得记下来的，不是页面长什么样，是「完成」这件事第一次被写成了可判定的条件：每条任务有判据，每次提交有结论，每个没做完的任务留下一条原因。
这套东西我现在做到骨架：表建好了，规则写完了，验收脚本能跑，页面还是占位。等第一个 sprint 的 verify 输出出来，我再补一篇，把红了多少次、改了什么一起写上来。