#WorkBuddy #Hy4｜用混元 Hy4 复盘一套固定资产管理系统的创作全过程：从一句话需求到可交付产品

这次我用混元 Hy4 完成的真实任务，不是"帮我写个系统"，而是把一套跑了三个月、迭代了二十多个版本的真实固定资产管理系统，复盘成一篇别人能照着做的结构化创作记录。本文记录我给 Hy4 的输入、它怎么把散落的材料组织成文、最终产出了什么，以及我对它的真实评价。所有项目事实、截图、踩坑均来自真实项目。

一、先把这次的"真实任务"说清楚

Hy4「体验官」活动要求用模型完成一次真实的创作或办公任务。我选了一个我觉得最能考验长文本能力的：复盘。

手上这套「本固固定资产管理系统」是个真实交付给客户的东西：Express + sql.js + React 18 + TypeScript + MUI 6 + Tailwind 3，从一句话需求做到 Windows 安装包，中间经历 v3.4 → v3.5 → v3.6.0（含四个 beta）→ 正式版，功能覆盖资产全生命周期、RFID 发卡、标签打印、折旧、盘点、RBAC、操作日志撤销、数据库备份恢复。

问题是：材料全都是碎的。几十轮对话记录、一份 CHANGELOG、几份验收清单、11 张截图、一堆踩坑笔记。要把它变成一篇逻辑连贯、别人读得下去、还能复用的长文，靠我自己整理得花大半天。

所以我给 Hy4 的任务是：基于这些真实素材，完成一次"创作过程复盘"的写作。这本身就是一次实打实的办公/创作任务，而不是让它凭空编一个项目。

配图1

二、我交给 Hy4 的输入（可直接复用）

我没有给一句"帮我写篇复盘"就完事，而是把约束一次性喂足。这是我实际用的提示词结构：

任务：把「本固固定资产管理系统」的创作全过程复盘成一篇结构化技术长文。
素材：CHANGELOG.md、docs/ 下的验收清单、11 张真实截图、踩坑笔记。
要求：
1. 三部分齐全：创作过程 / 成果 / 真实使用感受；
2. 结论先行，用表格承载事实；
3. 踩坑必须"现象 → 根因 → 修法"三段式，不许泛泛而谈；
4. 只写素材里真实发生过的事，版本号、数字不许编，不确定就标"待核"；
5. 结尾给可复用的提示词模板；
6. 中文，面向有真实开发经验的读者，不要营销腔。

关键在第 4 条。写这类复盘最大的风险是模型"顺手补齐"它觉得合理但其实没发生的细节。我明确要求它只写真实素材里有的，不确定就标出来——这直接决定了成稿能不能信。

三、创作过程：Hy4 是怎么把碎片变成结构的

阶段 1：先做归类，不急着写

我把 20 多轮的迭代记录和 CHANGELOG 一起丢过去，让它先输出一份"版本—主题—可写点"的三列表，不动笔。这一步很值：它把 v3.6 的四个 beta 正确归并成一条"RFID 发卡能力从 0 到 1 的工程化主线"，而不是四个孤立的版本号流水账。

我原本担心它会把 beta2/beta3/beta4 平铺成四节，结果它自己识别出这三版其实是同一条主线的连线状态可信 → 提示可信 → 出货可信，主动建议合并叙述、把篇幅让给真正的硬骨头。这个归纳判断是我没在提示词里指定的。

阶段 2：定骨架，把"踩坑"放到最重的位置

它给出的骨架是「结论表 → 输入材料 → 工作流 → 关键案例 → 产出物 → 踩坑清单 → 提示词模板」，并把踩坑清单标为"全文最值钱的部分"。我认可这个取舍：对同类读者来说，功能介绍各处都能看到，只有真实踩过的坑是稀缺的。

阶段 3：写，然后我来做"事实校验"

成稿出来后，我逐条核对了版本号、数字和结论。这里必须说真实感受里的不完美之处：它把一处权限点数量写成了记忆里的旧值（项目早期是 40+，后来迭代过），我指出后它立刻改并重扫了全文同类表述，但这个错是我抓出来的，不是它自己发现的。

所以我的结论是：Hy4 能扛住长文的结构、归纳和表达，但精确数字必须由人把关。我后来养成习惯——凡是涉及"多少个/第几版/百分之几"，一律让它标注来源文件，没有来源就写"以实际版本为准"。

阶段 4：把"感受"写出真实感，而不是夸

最后一部分我特意要求：不许写成"效率提升 10 倍"这种没依据的话，要写具体场景。它给出的落点是"长上下文里十几轮迭代不串味""说现象不说诊断时根因定位更准""AI 写得了代码写不了业务定义"——这些是能对应到实际操作的具体观察，比空泛吹捧可信得多。

配图2

四、成果：这次任务到底产出了什么

1. 一篇可直接发布的创作复盘长文（即本文），包含结论表、分阶段过程、三段式踩坑清单、可复用提示词模板。

2. 一套"复盘方法论"沉淀：先归类不动笔 → 定骨架定取舍 → 写 → 人对事实校验 → 感受写场景不写形容词。这套流程现在也成了我写其它项目复盘的标准动作。

3. 顺手把项目资产整理了一遍：为了喂素材，CHANGELOG、验收清单、截图被重新归档命名，11 张真实截图形成了固定的「配图清单」，后来发博客、做手册都直接复用。

项目本身的真实交付物（作为复盘对象，一并列出）：

配图3

配图4

五、几个真实踩坑（Hy4 帮我梳理成三段式）

这几条都是项目里真摔过的，也是 Hy4 在复盘时帮我从一堆笔记里挑出来、并整理成"现象 / 根因 / 修法"的：

坑 1：出货包接口提示全变乱码 - 现象：装到客户机器上，接口层 6 句中文兜底提示全变成方块乱码（U+FFFD 替换符） - 根因：client.ts 被存成 GBK，Vite 按 UTF-8 读，产物里恰好 63 个 U+FFFD - 修法：无损转 UTF-8 重建；并在打包链路加编码守卫，源码出现非 UTF-8 直接中止打包

坑 2：深层路由按 F5 整站白屏 - 现象：除首页外所有页面刷新白屏 - 根因：vite.config.ts 的 base: './' 配合 BrowserRouter，深层路由刷新时资源被 SPA fallback 返回 text/html - 修法：base 改回 '/'

坑 3：授权页机器码一直"获取中…" - 现象：拿不到机器码就无法激活 - 根因：硬件采集走外部进程最坏 60s，前端 axios 超时 30s，且 Promise.all 把整页卡住 - 修法：服务启动后台预热 + 接口快速兜底 pending:true + 前端拆开请求；改前先复现"已签发激活码仍有效"，没动候选集算法

Hy4 在这部分的价值不是"知道这些答案"（这些是项目实测结论），而是把散在十几个文件里的原始记录，统一成同一种可阅读的三段式，并且没把"现象"和"我当时的猜测"混在一起。

配图5

六、真实使用感受（不吹，也不藏）

亮点 1. 长上下文不串味：十几轮迭代、多个版本混在一起，它没有把 beta2 的改动安到 beta4 头上，也没把"盘点口径修正"和"发卡防误写"搞混。对长周期项目复盘，这点比文采重要得多。 2. 归纳强于罗列：我给的是流水账素材，它给的是"主线 + 分支"。主动建议合并四个 beta 那一下，确实省了我大量取舍时间。 3. 中文技术表达稳：不堆形容词，不写营销腔，能按"面向有经验的读者"这个要求控制语气。 4. 听得住约束："不许编数字、不确定标待核""感受要写场景"这类指令，它在全文里都守住了，没有中途跑偏。

不足 / 我会继续人工把关的地方 1. 精确数字会拿旧值：权限点数量那次串到了早期版本。凡涉及计数、版本号、百分比，必须人工核对来源。 2. 不会主动质疑素材：素材里若本身有矛盾，它倾向于自洽化而不是举手问。得我明确授权"发现冲突先列出来"。 3. 业务定义仍要人来：资产怎么分类、折旧从哪月开提、盘点有哪几种状态——这些它整理得很好，但"定什么"始终是我的活。

和以往体验的对比：以前做同类复盘，最耗时的不是写，是"从一堆记录里决定哪些该写、按什么顺序写"。这次把归类和定骨架交给 Hy4，我只做事实校验和取舍拍板，整体从大半天压到一两个小时。省的是组织成本，不是思考成本——这句话是我对这次体验最准确的总结。

配图6

七、可复用的提示词模板

任务：把 [项目名] 的创作全过程复盘成一篇结构化技术长文。
素材：[列出文件/截图/记录]
要求：
1. 三部分齐全：创作过程 / 成果 / 真实使用感受；
2. 先输出「版本—主题—可写点」归类表，确认后再动笔；
3. 结论先行，事实用表格；踩坑统一「现象 / 根因 / 修法」三段式；
4. 只写素材中真实发生的事，数字与版本号须标来源，不确定写「待核」；
5. 感受部分写具体场景，禁止「效率提升 N 倍」类无依据表述；
6. 结尾附可复用提示词模板；中文，不要营销腔。

第 2 条和第 4 条是我这次加的，也是最该保留的两条。

八、一点体会

用 Hy4 做这次复盘，我最大的收获不是"文章写得快了"，而是确认了一件事：长周期、多版本、材料碎片化的真实项目，恰恰是长文本模型最能体现价值的地方——前提是你把"什么能写、什么必须标待核"的边界先划清楚。

AI 能替你把散落的事实组织成结构，替你统一表达、控制语气、压缩取舍时间；但事实对不对、业务该怎么定、哪个数字是真的，还得你自己拍板。把这两件事分开，协作才既快又稳。

本文所有项目事实、截图与踩坑均来自真实项目记录，未使用任何虚构数据。欢迎交流长周期项目的复盘方法。