让智能体建项目管理工具：砍在数据上的三刀，和可以直接抄的提示词

引语：工具一天上线，真正花脑子的不是功能，是三个数据设计决策。每个决策都有一版被推翻的旧方案和失败证据，提示词原样贴在下面，改改就能用。

1. 起点：2991 所学校，现成工具装不下

手里有个真实需求：把 2991 所高校的开发者工作进展管起来——每周动态收集、求助事项 48 小时红标、按学校出周报，服务于码道CodeArts 的高校运营。第一反应找现成 SaaS，翻一圈放弃：我们的字段模型是「五级运营管道 × 八个专项」，动态只有进展/问题/求助/计划四类，SaaS 的工作项模型装不下这套词汇表，不如自己写。

选型极简：单文件 HTML 前端 + Python 标准库 ThreadingHTTPServer + SQLite（零第三方依赖），部署在已有外网服务器，nginx 用 /api/pipeline/ 前缀路由转到本机 3002。代码生成交给智能体（我用 Hermes Agent，本地跑 ），我的角色只剩把数据设计规则讲清楚。三刀，全砍在数据上。

动态提交 ──→ entries 表（只存事实）──四元组查重──同校同日同类型同描述→ 409
主数据刷新 ──→ schools 表（幂等灌库：新校 INSERT，老校只补负责人，不碰状态）
档案页读取 ──→ stage_of() 读时推断：手动覆盖值优先，否则取最高有正向动态的阶段
nginx /api/pipeline/ ──→ 127.0.0.1:3002（ThreadingHTTPServer + SQLite，零依赖）

2. 第一刀：阶段是存出来的，还是算出来的？

最初版是这么写的：每次提交动态，顺手 UPDATE 学校表的「当前阶段」字段。上线前自己推演了一遍，推翻。

失败证据很直白：动态有进展、问题、求助、计划四类。任何动态都推进阶段的话，一所学校提了条求助，档案页就显示它到了 Try 级——看板全是假进度。问题解决了阶段要不要降回去？降级时机谁定？状态跟着事件走，这两个问题永远缠不清。

改法：阶段不落库，读时算。学校表只存手动覆盖值，页面现场推断：从五级管道由低到高扫动态，取最高有正向动态的阶段；正向只认进展和计划——提了求助不代表做到了那一层；手动覆盖值优先，设定后自动推断不再生效。

推断逻辑十行（可以直接抄，变量名改你的）：

STAGES = ["space", "discover", "try", "adopt", "engage"]

def stage_of(school, entries):
    """当前阶段：手动值优先，否则取最高有正向动态的阶段"""
    cur = school["stage_current"]
    if cur and cur != "space" and not cur.startswith("auto:"):
        return cur, True
    reached = "space"
    for st in STAGES:
        if any(e["stage"] == st and e["type"] in ("progress", "plan") for e in entries):
            reached = st
    return reached, False

这一刀的教训：**存事实，算状态。**动态表只存发生过什么，「现在到哪了」永远现算。

3. 第二刀：防重，用索引还是先查后插？

用起来第二天就撞见重复：周会上两人各录了一条一模一样的动态。防重方案有两个：数据库唯一索引，或应用层先查后插。

唯一索引的诱惑是「数据库保证」；可事件描述是 5-500 字自由中文文本，500 字塞进索引键写入路径变重，改个标点就绕过——索引防完全相等，防不住换说法。

最终先查后插：同校同日同类型同描述，命中返回 409 不写入。接受「改标点绕过」的理由：追踪工具里重复的真实来源是整句复述——补录、转述都是整段照抄；刻意改标点的不是要防的敌人，不值得养一个大文本索引。

对应的提示词（可以直接抄）：

给动态提交接口加防重，按下面的定义实现，不要建数据库唯一索引：
1. 重复的定义：同轨道内，归属对象相同 + 事件日期相同 + 类型相同 + 事件描述全文相同。
2. 命中重复返回 409 和明确错误文案，不写入。
3. 事件描述是 5-500 字自由文本，重复的真实来源是整句复述；
   改标点绕过不是要防的敌人，不为此维护大文本索引。

这一刀的教训：**先定义什么算重复，再选去重的手段。**定义清楚了，手段反而简单。

4. 第三刀：全量刷新，凭什么不动手工数据？

学校主数据来自权威清单导出的 JSON。第一版灌库全量覆盖：清表重灌。上线当天运营手动标了十几所学校的阶段，第二天清单更新重新灌库，全没了——三个决策里唯一上线后才暴露的。

修法是幂等三规则：只新增——库里没有的学校 INSERT；只补不盖——已有的学校只更新负责人标记，其余字段不碰；严禁全量 UPDATE 和 DELETE。口诀：主数据只补不盖，手工状态是权威。

对应的提示词（可以直接抄）：

写一个从 schools_full.json 灌学校主数据的函数，要求幂等，规则三条：
1. 只新增：库里没有的学校 INSERT，带全字段。
2. 只补不盖：库里已有的学校只更新负责人标记，其余字段一律不碰。
3. 严禁全量 UPDATE/DELETE——本地手工维护的状态字段是权威数据，
   外部 JSON 只负责补全学校清单，不负责覆盖运营状态。

这一刀的教训：**凡是有外部数据源要灌进来的表，动笔前先声明哪些字段归谁管。**说不清归属，刷新就是事故。

5. 意外收获：一行哨兵数据省掉一张表

工具还有一类动态不挂学校：IT 平台建设、课程包生产这类能力事项。标准做法是单建一张表、加一套 Tab。我偷了个懒：在学校表里插一行 id=0 的哨兵行「—（能力专项）」，能力动态全挂它名下，表结构、查询、前端渲染一行没改。

小工具的数据模型，复用优先于范式正确——前提是在哨兵行上写清「勿删」，别让后来人当脏数据清了。

6. 总结

三个判断收尾。第一，状态是算出来的，不是存出来的：动态存事实，进度是视图，混在一张表里怎么改都是错的。第二，去重的定义比手段重要：先回答「什么算重复」，手段自然简单。第三，数据灌入必须先划地盘：字段归外部还是归本地手工，动笔前写死，刷新才不是事故。

这三个决策没有一个是写代码时想到的，全是在提示词里跟智能体拉扯出来的。工具的复杂度不在代码里，在你能不能把规则一句话讲清——讲不清的规则，生成的代码一定替你含糊。

作者：林华鼎 · 华为云开发者发展与支持部 · 科技博主系列