上班鼓励器：用 DeepSeek Harness 把一个 dsh 插件做成微信小程序
2026-11-05 晚上十点，我在 DeepSeek Harness 里敲下第一段需求。100 分 16 秒后，小程序 v1.0.0 已经上传到微信开发版；11-05 深夜提交审核，11-06 上午审核通过并发布。
这篇文章不复述代码，而是回答四个问题：这个想法是怎么落地的、参考了哪个微信小程序、我到底怎么用 DeepSeek Harness、哪些事只能人来做。
缘起：一个只能自己看的插件
「上班鼓励器」最初是 DeepSeek Harness 的一个 Web 插件（dsh-plugins/work-encourager，React + localStorage）：填上月薪、固定支出和上下班时间，它就把上班时间换算成看得见的钱——今日实时收入、进度条、时薪、净收入，外加一个按月记账和导出 Excel 的小本子。
它很好用，但有一个硬伤：只有打开电脑上的 Harness 才能看。手机上没有，数据在 localStorage 里，换台机器就没了。于是有了把它搬到微信小程序上的念头：打开微信就能看到今天已经赚了多少，顺手还能记一笔账。
这就是「想法落地」的第一步，也是最容易忽略的一步：先想清楚边界。我在第一条需求里就把能想到的约束全写了进去：
我打算把上班鼓励器（dsh插件）迁移到微信小程序。前置知识：1. dsh插件 在 ……；2. 我有一个云服务器（……，有域名 guangze233.com，已备案）当作后端接口代理；3. 我有一个开发服务器 10.11.12.21 …… 和云服务器通过 zerotier 已经组网联通了。现在帮助/指导我实现这个小程序，我的预想是：技术栈是微信小程序 + springboot + mysql（可用若依框架，强调框架代码和业务代码需要隔离开……）；部署设想 微信小程序请求 https://guangze233.com/open-api/业务代号/xx，云服务器反向代理到开发服务……；功能暂时设想有 a. 静默登录 b. 设置月薪、固定支出、上下班时间、随时记账 c. 主页实时收入与收支 d. 时间范围趋势 e. 管理后台暂不做……
需求里信息密度越高，后面来回确认就越少。这份「预想」一共包含技术栈、部署形态、功能边界、基础设施四类约束，为后面的方案文档省了大量时间。
想法落地：先定口径，再写代码
DeepSeek Harness（下称 DSH）没有立刻开始写代码。它做的第一件事是现场勘查：
- 读原插件的
client.js，把收入计算口径、记账字段、Excel 导出逻辑全部还原出来； - 远程登录开发服务器，确认 Ubuntu 版本、8C/7.4G、100G 根分区、Docker 版本、镜像源；
- 确认云服务器上 nginx 的现状、
guangze233.com的证书（顺便发现证书 3 天后到期）； - 摸排本地工具链，发现
D:\workspace\...的若依基线工程可以直接复用； - 派一个子代理去查外部事实：微信小程序 request 合法域名规则、
wx.login的隐私合规、导出 Excel 的正确姿势、Spring Boot/JDK 版本、若依分支、小程序 UI 库……
注意这个顺序：查事实 → 出方案 → 找人拍板 → 才开工。 第一轮结束时，它交付了一份 docs/01-系统设计方案.md，外加一张「需要你拍板的 6 个问题」清单：
- 小程序 AppID / 主体是个人还是企业？
- 云服务器凭据给不给？
- 实时收入按「实际到手」还是「月薪」算？
- 工作日只算周一到周五，还是要接法定节假日/调休？
- 只自己用还是多人用？
- 项目起点用不用现有的若依工程？
我的回答直接变成了设计文档里的「决策记录」：个人主体、按月薪算（去掉实际到手）、工作日周一~周日可复选（默认周一到周五）、多人使用（按 openid 隔离）、干净若依 + 独立业务模块 biz-work-encourager。这些口径一旦定下来，后面所有页面、接口、公式都围绕它展开，几乎没有返工。
最终的架构是这样的：
一条请求的完整路径：小程序 → https://guangze233.com/open-api/work-encourager/v1/** → 腾讯云 nginx（TLS + 只反代这一个前缀）→ ZeroTier 内网 10.11.12.21:8080 → Spring Boot（systemd + 宿主 JRE 21）→ MySQL 8.4 / Redis 7.4。云服务器只做反代，不部署业务服务；真正的后端跑在家里那台开发服务器上。
几个当时拍板的工程决策，后来都被证明是对的：
| 决策 | 原因 |
|---|---|
若依框架代码一行不改，业务全在 biz-work-encourager 模块 |
升级框架不影响业务；出问题能定位到模块 |
小程序接口用自定义头 X-WX-Token，不用 Authorization |
若依的 JWT filter 只读 Authorization，用它每个请求都会打一条 error 日志 |
金额全链路用「分」（BIGINT，字段后缀 Cents） |
浮点数算钱早晚出事 |
实时收入不在服务端轮询，/dashboard 只下发时间与日薪，小程序本地每秒重算 |
服务端 QPS≈0，进度条还顺滑 |
每日快照表 biz_we_daily |
以后改月薪，不会篡改历史趋势 |
从 P0 到 P5 的落地节奏也很清楚：P0 骨架 → P1 登录+首页实时收入 → P2 记账 → P3 趋势+Excel → P4 部署与公网反代 → P5 提审材料与上传。原插件的能力到小程序的映射，在方案文档里被逐条对齐：实时收入 → 首页 Hero 卡片；设置 → 云端存储；记账 → 服务端分页与按月合计；Excel → 服务端 POI 生成；中英文双语被砍掉、localStorage 换成了云端存储。
参考别人的小程序：一张截图带来的视觉重做
数据链路跑通之后，小程序能用了，但不好看。我在微信里看到一个同名的「上班鼓励器」，把截图发给了 DSH：
可以参考别人的鼓励器，现在过于朴素了：
#小程序://上班鼓励器/fqEStX7YhPSRLZy
那个分享链接只能在微信里打开，DSH 能参考的只有截图：
它的视觉语言非常清晰：暖红主色、超大号数字、状态胶囊 + 进度条、把工资拆成「日薪 / 时薪 / 分薪 / 秒薪」、本月已挣 + 剩余工作日，以及一组「摸鱼记录」的胶囊入口。
DSH 做了一轮整体视觉升级，只借视觉，不抄产品逻辑：
| 参考图的元素 | 我们的做法 |
|---|---|
| 顶部「别卷了，下班了」+ 日期 | 随状态变化的人话标题：还没上班，再躺会儿 / 上班中，稳住 / 别卷了，下班了 / 今天休息，别卷 |
| 超大红色金额 + 状态胶囊 + 进度条 | Hero 卡片：¥ 小字 + 超大整数 + 小数、距下班 01:23:45 胶囊、红色渐变进度条 |
| 本月已挣（可隐藏）+ 剩余工作日 | 两张中卡，眼睛可切换 ¥ **** |
| 日薪 / 时薪 / 分薪 / 秒薪 | 2×2 小卡，全部按真实口径实时计算（秒薪 4 位小数） |
| 摸鱼记录 tab 胶囊 | 换成真实可用的「记一笔 / 看趋势 / 改设置」 |
| 暖红主色 | 主色统一 #e5484d、背景 #f6f4f2、卡片大圆角 |
它没有抄「暂停计薪 / 打卡 / 摸鱼小记」这些功能——我们的产品口径是「月薪 ÷ 当月工作日」的工资时钟，和打卡计时是两套逻辑。这个取舍很重要：参考的是视觉，不是别人的产品定义。
改造后的小程序首页：
这轮改造还顺手修了一个真机隐患：WXSS 对 :first-child、:last-child、相邻兄弟选择器的支持不稳定，全部换成了显式 class，避免真机上样式丢失。
我是怎么用 DeepSeek Harness 的
这是全文的重点。一句话总结：我不是让它「一句话生成一个项目」，而是把它当成一个能自己查资料、自己排期、自己验证、还会主动来找我对齐的工程搭档。
先看几组从当晚会话记录里统计出来的数据：
| 指标 | 数值 |
|---|---|
| 会话 | 5 个（主会话 + 技术调研子代理 + 前端 teammate + 发布后追问 + 本次博客） |
| 主会话 | 23 个回合、362 个模型步；自动续跑 9 轮（上限 15 轮） |
| 工具调用 | 主会话 557 次、全程 812 次（pwsh 213、write 192、read 56、edit 40……） |
| 后台任务 | 主会话 213 个 job，22 个超过 60 秒，11 个被 kill |
| 外部调研 | 22 次 web_search、43 次 web_fetch |
| 上下文 | 11 条工具结果被裁剪，合计 73,410 tokens |
| 模型 | 全程 deepseek-flash（reasoning high、1M 上下文），没有换过 |
| token | 输入约 186 万、输出约 67 万（另有 1.64 亿缓存命中） |
| 产出 | 6 个页面、12 条接口路由、5 份项目文档、1 份 AGENTS.md |
1. 让它先查事实，再给方案
第一轮它没有写一行业务代码，而是并行做了三件事：读原插件源码、远程勘查服务器、派子代理核实外部规则。子代理用的是 web_search + web_fetch（22 次搜索、43 次抓取），最后交回一份带来源的结论清单，直接纠正了几个我原本的理解错误：
- 小程序 request 域名不强制 443，但配了端口就只能用该端口；域名必须 ICP 备案；
- 配置 request 域名不需要校验文件，只有 web-view 业务域名才要；
wx.openDocument必须传showMenu: true，否则用户无法转发/另存；- JDK 24 不是 LTS（我原话说的是 JDK 24），建议 JDK 21/25；
- 个人主体选「工具-记账」类目是官方开放的。
「先查事实」比「先生成代码」值钱得多：这些结论每一条都影响方案，查错一条后面就要返工。
2. 把目标写成长期目标，让它按轮次自己推进
方案确认后，它把这个项目登记成一个长期目标（goal）：
把「上班鼓励器」dsh 插件迁移为微信小程序（原生 + 若依 RuoYi 3.9.0 业务模块 biz-work-encourager + Spring Boot 3.5 + MySQL 8 + Redis，JDK 21 LTS）。按 docs/01-系统设计方案.md 推进：P0 工程骨架与 docker-compose 基础设施 → P1 静默登录与收入设置 → P2 首页实时收入与记账 → P3 趋势与 Excel 导出 → P4 开发服务器部署 + 腾讯云 nginx 反代 + 微信域名配置 → P5 提审上线。每轮开始先对照方案第 12 节检查待确认项，未确认前只做不依赖业务口径的骨架工作；所有框架代码（ruoyi-*）保持不动……
然后它开始自动续跑：Round 1、Round 2……一直到 Round 9（上限 15 轮，第 9 轮后主动 blocked）。每一轮它自己决定「这轮做什么、怎么验证」，做完给我一段汇报：已完成什么（带证据）、需要我做什么、下一轮计划。最长的一轮是 Round 2（26 分 56 秒），一口气串完了趋势聚合、Excel 导出、月薪余数修正、Docker 构建失败改部署形态、腾讯云 nginx 反代五件事。
这是整个体验里最不一样的地方。普通的 AI 对话是「你问一句它答一句」；而带长期目标的会话是「我睡了一觉，它把 P2、P3、P4 做完了，还在等我拍板 P5 的微信后台操作」。开发期间我一共只回了 8 条消息，其余时间都是它在跑。
而且人随时可以插话，目标不会丢：23:02 我丢了一张参考截图，它开了一个新回合做视觉升级，做完自动回到 Round 2；23:48 我回答「证书不用管、域名配好了、不用真机」，它切完生产配置又继续 Round 7。目标状态一直挂着，处理完人工回合就接着往下走。
它还会自己判断什么时候该停：P5 的最后一步是「在微信公众平台提交审核」，这必须由小程序管理员登录操作。它连续三轮（Round 7、8、9）卡在同一个条件后，主动把目标标记为 blocked，并写清楚「我试过哪些替代路径、为什么做不到、需要你点哪几个按钮」：
唯一剩下的是在 mp.weixin.qq.com 后台「提交审核 → 审核通过后发布」。这一步必须由小程序管理员登录微信公众平台操作：当前会话只有微信开发者工具登录态，开发者工具 CLI 没有「提交审核」命令，我也没有微信公众平台的登录态，无法代你提交审核。……期间试过的替代路径：CLI 全部命令确认无提审能力；mp 后台无可用登录态；没有第三方平台授权可走 submit_audit 接口。
那天晚上我回的最后一句是「今天就这样吧，工作先结束。明天审核通过了，我测试后再找你」——剩下的按钮，确实只能我来点。
3. 文档即上下文
整个项目只有 5 份文档，但每一份都在关键位置发挥作用：
| 文档 | 作用 |
|---|---|
docs/01-系统设计方案.md |
架构、决策记录、数据模型、接口、部署、安全、分期计划；每轮开工前先读它 |
docs/02-数据库设计.md |
表结构、金额/时区约定、查询口径 |
docs/03-接口契约.md |
每个接口的请求/响应，前后端按它对齐 |
docs/04-提审清单.md |
域名、隐私指引文案、版本说明、提审检查清单 |
docs/05-验收报告.md |
交付范围、验证证据、运行手册、遗留事项 |
还有第 6 份不算「文档」的东西：**AGENTS.md**。项目收尾时我问了一句「我新开一个会话，你还能知道我们做过这个系统吗」。它没有打包票，而是写了一份交接说明，把项目是什么、部署在哪、常用命令、关键约定、下一步全部写进去。后来新会话就是靠这份 AGENTS.md 自动恢复上下文的——这比把聊天记录翻出来有效得多。
4. 并行：子代理、teammate、任务板与后台任务
这个项目能在一个晚上从 0 做到可提审，很大程度靠并行：
- 子代理：一个专门做技术调研（就是上面那份事实清单），查完就结束，不占主会话的上下文；
- teammate：P1/P2/P3 的前端页面交给一个叫
mp-client的常驻队友，它只被允许改miniprogram/目录，和我在写的server/完全不重叠； - 任务板：每个前端任务都写成带验收标准的任务卡，把后端接口契约原文贴进去，它交付时按「改动文件 / 关键实现点 / 验证命令与结果 / 需要你确认的契约细节」的格式汇报；
- 后台任务：全程 213 个后台 job——Maven 编译、启动后端、拉 Docker 镜像都在后台跑，用
job_output回收结果；22 个超过 60 秒，5 个超过 5 分钟，最长的一个跑了 27 分钟（本地java -jar常驻进程，最后被 kill）。等待期间它继续做别的事，不会干等。
前端 teammate 的汇报里有一个我很喜欢的细节：它自己写了 mock wx/App/Page 的运行时 harness，在 Node 里跑 60+ 断言，还把 P1 的测试固化成回归用例，做 P2、P3 时每次重跑。这不是我要求的，是它觉得「应该证明自己没改坏东西」。
5. 验证闭环：它自己证明自己做完了
DSH 在每轮汇报里都会给出可复现的证据，这是我最看重的一点：
- 单元测试：14 个 JUnit 用例（收入口径、跨天班、休息日、日薪余数分摊、记账校验、幂等）；
- 前后端 E2E：用 Node 的
wxshim 直接加载小程序的services/*.js，打真实后端，22 项断言覆盖登录→设置→首页→记账 CRUD→趋势→导出； - 生产同款 E2E：同一份小程序代码走
https://guangze233.com再跑一遍 22 项断言； - 运维验证：公网
/health返回db=UP redis=UP、限流实测（连打 35 次登录，30 次通过 5 次被拦）、备份恢复演练、发布失败自动回滚。
E2E 还真的抓到了一个线上级 bug：DELETE /expenses/{id} 把 deleted 放在了响应顶层，而小程序 request.js 统一解包 data，前端拿到的永远是 undefined。这种「两个端都觉得自己对」的问题，只有真实联调能发现。
6. 它也会犯错：几个事故与修复
写这一节是为了说明：它不是不会错，而是错了能自己发现、自己修，而且会把修复过程讲清楚。
- 开工第一分钟就翻车：工作区的 Windows 权限坏了，连
Get-Location都起不来。它没有硬试，而是调用了内置的diagnose-windows-sandbox-acl技能，检查路径及各级上级目录的 ACL，只补当前用户的权限，并留下备份与撤销脚本。这是那次会话里唯一一次审批请求（当时还是「每次操作都要问」的策略），审批文案写得像人话：「这个工作区文件夹的 Windows 文件权限挡住了我执行任何命令……不改动任何文件内容、不改变文件夹所有者，每一处修改都会先备份并在最后打印撤销命令。」我点了允许之后它才继续；随后我把权限切成danger-full-access+ 不再询问，之后整晚再没被打断过。 - 镜像拉不动：Docker 镜像源只有 ~50KB/s，MySQL 镜像要下几个小时。它换了几个源，最后放弃「后端也进容器」的方案，改成宿主机 JRE + systemd 跑 jar，MySQL/Redis 继续用 compose。这个混合部署形态后来一直很稳。
- 若依异常处理器抢戏：业务校验错误本该返回
code=400，实际被若依自带的GlobalExceptionHandler抢先处理成 500。它给业务模块的 advice 加了@Order(HIGHEST_PRECEDENCE)解决。 - 自己写的补丁工具把自己坑了：一次用 PowerShell 写补丁文件时带了 BOM，补丁工具把「空字符串」当成替换源，把两个 Markdown 文档的每个字符之间都插入了重复文本，文件被撑到 6MB。它定位后发现插入串是已知的，用
split(N).join('')精确还原，并给工具加了「拒绝空 old + 自动去 BOM」的硬保护。 - 自查出一个路径穿越漏洞：
/open-api/.../../../system/user/list能穿过 nginx 打到若依后台接口（虽然只返回 401）。它把 nginx 的反代前缀收窄到/open-api/work-encourager/，并增加含../编码点段的请求直接 404。 - CLI 没有「提交审核」：微信开发者工具 CLI 只有 upload/preview，没有提交审核。它用 CLI 把
v1.0.0上传成功（66KB），然后老老实实把这一步标成 blocked，而不是假装完成。
7. 上下文管理与会话交接
主会话最后被裁剪过一次上下文：11 条早期的工具结果被压缩掉（合计约 7.3 万 token），只保留结论。所以到收尾阶段它还记得「证书 11/8 到期」「日志统一到 /opt/work-encourager/backend/logs」这些关键事实。
真正解决「聊太久会忘」的是 AGENTS.md：换一个会话，新会话在注入工作区指令时自动读到它，就知道项目是干什么的、部署在哪、卡在哪一步。AI 的记忆不该靠聊天记录，而该靠仓库里的文件。
8. 我下次会这么开局
如果你也准备用 DSH 做类似的事，我建议按这个顺序开局：
- 一段信息密度足够高的需求：产品是什么、给谁用、技术栈倾向、部署形态、明确不做什么；
- 先要方案，不要先要代码：让它现场勘查 + 查外部事实，产出设计文档，并把「需要你拍板的问题」列出来；
- 拍板后建长期目标：把里程碑（P0–P5）和验收标准写进目标，让它按轮次自动推进；
- 给它验收工具：单测、真实接口 E2E、部署后的健康检查——没有验证手段的自动续跑等于盲跑；
- 每轮只问三件事：已完成什么（带证据）、需要我做什么、下一轮计划。
一个可以直接抄的开场白：
我要做 ……（一句话产品）。技术栈倾向 ……，部署在 ……，用户是 ……。请先勘查环境、查清外部规则，输出一份设计方案（架构 / 数据模型 / 接口 / 部署 / 分期），列出需要我拍板的问题；我确认后再开始写代码，并把整个项目登记为长期目标，按 P0–P5 推进。每轮汇报请包含：已完成（带验证证据）、需要我做什么、下一轮计划。
人需要做的部分
这一段是我最想写清楚的部分。AI 可以把工程做到「可验证的完成」，但有几类事它天然做不了，或者不该替你做。
1. 真实世界的账号与凭据
- 注册小程序、拿到 AppID 和 AppSecret；
- 云服务器的 root 凭据、开发服务器的账号密码；
- 域名与 ICP 备案、HTTPS 证书；
- 微信开发者工具里登录的微信账号。
这些东西不在代码里，AI 也拿不到。我能做的就是在它明确要的时候给，并且尽量把凭据放在环境变量/本地配置文件里，不进仓库、不发群。
2. 只有管理员能点的按钮
- 在 mp 后台配置
request 合法域名和downloadFile 合法域名（后者漏配，导出 Excel 在真机上会直接失败）； - 填写隐私保护指引、服务类目、版本说明；
- 提交审核、审核通过后发布；
- 证书续期（这次是我自己处理的）。
这一步 AI 只能帮你把材料准备到「你点两下就行」的程度，但按钮必须你自己点。它也诚实：连续三轮卡在同一条件后，主动把目标标成 blocked，而不是编一个「已完成」。
3. 拍板业务口径
「按实际到手还是按月薪」「工作日是否接法定节假日」「只自己用还是多人用」——这些没有标准答案，取决于你的真实需求。AI 能做的是把选项、代价、影响讲清楚，让你选。
4. 验收与兜底
它会给出一堆证据，但最终验收必须是人：真机打开小程序看一眼、导出一次 Excel、点一下审核。这次我选择跳过真机联调（属于风险自担的偷懒），审核却顺利通过了；但如果被驳回，改代码、重新上传、重新提交的循环还是得人来配合。
5. 事后运维与判断
上线后数据库里多了 5 个真实 openid，我第一反应是「一上午来了 5 个人？」。它去数据库里查了一遍：3 个是上传后 30 秒左右连续登录、没有任何设置数据，像是开发者工具/测试账号留下的；1 个填了月薪 13000、固定支出 4622（应该就是我）；还有 1 个早上登录后没设置。同时它发现一个隐患：本地开发环境和线上共用同一个数据库，开发期的真实登录测试数据会混进线上用户表——这个架构问题它当时实现时没有意识到，是我追问之后才一起复盘的。
所以「人需要做的部分」里还有一条：保持怀疑，尤其是那些「跑通了但没人问过为什么」的地方。
6. 如果你也想复刻一遍：人类这边的准备清单
- 账号：微信小程序账号（个人主体也能选「工具-记账」类目）、AppID 与 AppSecret；
- 服务器：一台能跑 Docker 的 Linux 机器（MySQL/Redis 用 compose），再加一台能公网访问的机器或云服务器做 nginx 反代；
- 域名：已 ICP 备案的域名 + 有效 HTTPS 证书（小程序只认 https）；
- 工具：微信开发者工具（上传开发版、看真机效果）；
- 时间：真正花时间的是「对口径」和「点审核」，不是写代码；
- 心态：把它当同事而不是许愿池——它交付的是可验证的工程，审查和兜底仍然是你的工作。
一张分工表
| 环节 | 人 | DeepSeek Harness |
|---|---|---|
| 提出想法、写清约束 | ✅ | 追问细节、补全边界 |
| 技术调研、方案设计 | 拍板 | ✅ 勘查、查资料、写文档 |
| 代码实现（前后端） | 验收 | ✅ 主体实现 + 单测 |
| 部署与公网链路 | 提供服务器 | ✅ 部署、反代、验证 |
| 微信后台配置 | ✅ 只有管理员能做 | 提供逐项清单 |
| 提交审核 / 发布 | ✅ | 准备材料、上传开发版 |
| 线上问题排查 | ✅ 触发 | ✅ 查日志、查库、定位 |
上线之后
- 小程序包体 66KB / 67,618 字节（单包，无 npm 依赖，趋势图是原生 canvas 手绘的）；
- 6 个页面：首页、记账、趋势、设置（我的）、引导、用户协议与隐私政策；
- 后端 7 个 Controller、12 条接口路由：静默登录、用户与设置、首页、记账 CRUD、趋势、Excel 导出、健康检查；
- 后端 43 个 Java 文件、数据库 35 张表（若依系统表 18 + Quartz + 业务表 4）；
- 14 个单测（收入计算 5 + 记账 6 + 趋势 3）+ 22 项前后端 E2E 全过，生产域名同款 E2E 也全过；
- 运维：登录 30 次/分、记账 120 次/分、导出 20 次/分的限流，5 分钟巡检（含证书到期告警），每日备份，发布失败自动回滚。
从第一段需求到 v1.0.0 上传，一共 100 分 16 秒；主会话模型的实际工作约 1 小时 48 分。
我更愿意记住的是时间线：
| 时间 | 发生了什么 |
|---|---|
| 11-05 22:10 | 第一条需求，开工 |
| 11-05 22:12 | 技术调研子代理启动 |
| 11-05 22:21 | 方案文档 + 6 个待拍板问题 + 创建长期目标 |
| 11-05 22:38 | 开发服 MySQL/Redis healthy |
| 11-05 22:49 | P0 完成（若依基线 + 业务模块 + 小程序骨架） |
| 11-05 22:57 | P1 全链路通，Round 1 自动续跑开始 |
| 11-05 23:02 | 我发参考截图，触发视觉改版 |
| 11-05 23:05 | Round 2：趋势 + Excel + 部署 + 反代（26 分 56 秒） |
| 11-05 23:32–23:48 | Round 3–6：提审材料、生产加固、14 个单测、E2E、回滚脚本 |
| 11-05 23:49 | 用开发者工具 CLI 上传 v1.0.0（66KB） |
| 11-05 23:51 | 目标 blocked（只剩提交审核） |
| 11-05 23:53 | 提交审核（我操作，平台侧无日志） |
| 11-06 上午 | 审核通过 → 发布 |
| 11-06 14:37 | 发布后追问「5 个用户」 |
| 11-08 | 写这篇复盘 |
复盘：这套用法适合什么、不适合什么
收益
- 一个晚上，从 0 到可提审的完整工程：后端、前端、数据库、部署、反代、测试、文档、运维脚本；
- 我做的是「真实世界里只有我能做的事」：给账号、拍口径、配域名、点审核；
- 全程可审计：每轮有汇报、每个结论有证据、每个决策有文档、交接有
AGENTS.md。
代价与边界
- 它需要被 review。我至少拦下过「验证方式是否真的可信」「本地库和线上库是否该分开」这类问题；
- 它会在「差一步真实世界操作」的地方停下，这恰恰是对的；
- 它对微信生态里的分享链接、审核规则这类只能人工确认的信息，只能靠截图和搜索，不能全信；
- 成本不是零：全程 505 次模型调用、812 次工具调用，输入约 186 万 token、输出约 67 万 token（另有 1.64 亿缓存命中）；长时间自动续跑会消耗额度，项目越大越需要好的文档和验收标准来控制方向。
下次我还会这么用，但会加三件事：一开始就把「本地开发库和线上库隔离」写进方案；把每轮汇报的「需要人做什么」集中成一个 checklist；以及——把 AGENTS.md 从第一天就开始写，而不是最后一天补。
后记：这篇博客也是这么写的
写完正文之后，我让 DSH 用 Agent Teams 做了三件并行的事：一个队友去挖掘 11-05 那次开发会话的日志（3260 条记录），整理成「DSH 使用实录」；一个队友去调研我这个 Hexo 博客的 frontmatter/图片/构建规范；还有一个队友用 draw.io 画了文中的架构图和协作流程图。这篇博客的配图、数据、时间线，基本都是从那晚的会话日志里捞出来的——它连自己怎么被使用的，都能写下来。
如果你也想把一个想法变成真正能用的东西，我的建议是：先把它写成一段信息密度足够高的需求，然后找一个能自己查、自己排期、自己验证的 AI 搭档。剩下的，就是你愿不愿意为真实世界里的那几个按钮负责了。
项目代码：
D:\workspace\guangze233\work-encourager（微信小程序 + Spring Boot/若依 + MySQL/Redis）
参考的小程序：见文中截图（仅作视觉参考，未使用其代码与产品逻辑）
本文的会话资料整理、配图与初稿由 DSH 协助完成，作者校对后发布。