DSH Dev Workflow
一个人 + 一个 AI，也能做出有章法的东西。
选一个人设开始聊想法，它记下你的原话、拆成任务、真跑一遍验证 —— 换 session、隔一周回来，都还接得上。
> DSH 的轻量开发 workflow 插件。 三个零件：一个会记账的人设（preset）、一块只读看板、一条
> Request → Feedback → Task → Verify → Completion 的流程。为「一个 plugin、一个小工具、一个人的小应用」
> 而做 —— 不是给大团队用的研发管理平台。
先说清楚它是给谁的
| 适合 | 一个 plugin、一个脚本、一个自己每天会用的小应用；想法还很模糊，想先聊出来再定；对话横跨几天、几个 session；你一个人，或者两三个人，不需要 Jira 和站会 |
| 不适合 | 多人协作的正式研发项目（没有角色、权限、代码评审、CI 集成，也不打算做）；需要合规审计与跨团队流程治理的场景；期待「一句话自动生成整个产品」的场景 |
一句判断标准：如果你的项目能用「我一个人 + 几个晚上」描述清楚，它就是为你做的。
如果你需要的是「谁在什么时候改了哪行、走什么审批流」，请去找 Issue 系统 —— 这个插件不解决那个问题，也不假装能解决。
你是不是也这样
- 想法是散步时冒出来的，坐回电脑前只剩一句「那个东西挺好的」。
- 前天说清楚了需求，今天 AI 又问一遍「你希望在哪个页面改？」。
- 「应该跑通了吧？」—— 然后发现根本没跑过，或者跑过但忘了退出码是几。
- 一个功能改了五轮，第五轮和第一轮到底哪句话算数，翻聊天记录也翻不出来。
- 上周那个 session 里的结论，这周开新窗口就人间蒸发了。
这些不是模型不够聪明，是上下文和决策没有落盘。这个插件做的事很朴素：把你亲口说的话、定下来的事、
真跑过的命令，留在项目目录里，并且让 agent 每次都先读它。
它做三件事
一、人设：一个会记账的搭档
新建会话时选 preset「研发助手 · Dev Assistant」。它不是任务清单机器人，也不是「自动驾驶按钮」，
而是换了性格的工作协议：
- 你说需求，它先存原话（
rawQuote，不改写、不润色），再问你验收条件； - 你给反馈，它留你的原话 + 决策（接受 / 拒绝 / 延后），并且不会把一次偏好悄悄升级成团队规范；
- 它不说「应该测过了」—— 要么有命令和退出码，要么这条任务不算完成；
- 破坏性动作（推送、发布、删数据）先停下来，把风险摊开给你选。
核心优先级写在 persona 里：安全硬边界 > 仓库规范 > 项目目标 > 用户偏好 > 本次需求。
二、看板：想法不再埋在聊天里
左侧边栏点「研发看板」，就是这个工作区的全部记录：
- 四列：需求（未终结的：你的原话 + 验收）、待办（已建任务）、待确认（
waiting-user，需要你点一下头）、已完成。已交付/作废的需求由dev_request_close给终态，不再占着需求列。 - 三个过滤：进行中 / 已完成 / 全部，计数与列表同源，不会各算各的。
- 只读：看板只调一个 GET 路由，只打开
<工作区>/.dsh-dev/里那几个已知 JSONL，不写任何记录。 - 换个工作区即换项目：记录按项目隔离，一个人同时维护几个小项目也不会混。
三、流程：五步，每一步都能被回看
你的原话 ──→ 可执行任务 ──→ 真实命令 ──→ 带证据的收口
↘ 反馈与决策 ↗ ↘ 可复盘的知识 ↗
| 步骤 | 落下来的东西 | 为什么重要 |
|---|---|---|
| Request | 原话、范围、验收条件 | 三天后还知道当初到底要什么 |
| Feedback | 原话、决策、影响 | 改主意是被记录的，不是被遗忘的 |
| Task | 步骤、依赖、风险、验收 | 下次接着做，不用重新推理 |
| Verify | 命令 + 退出码 + 结果 | 「完成」有证据，不靠形容词 |
| Completion | 变更文件、证据、风险、未完成项 | 交接给人或交给未来的自己 |
一个想法的一生
下面是一段示意（脱敏改写），每一步都对应真实存在的记录结构：
Day 0 21:40 你：我想做个小插件，把当前窗口的标签页收成一个清单，能导出 markdown。
先能跑就行，别装依赖。
→ 需求登记（原话照抄）
验收：读得到当前窗口标签页 / 能导出 .md / 不新增依赖
21:52 → 拆成 3 个任务：读标签页、生成 markdown、写一个 smoke 门禁
22:20 实现跑起来了。验证记录：node verify/smoke.mjs exitCode 0
Day 1 09:10 新 session。你：顺手加个按域名分组吧。
→ 反馈登记（原话）+ 新任务「按域名分组」，依赖前面那个拿标签页的任务
Day 3 回来只问一句：「上次导出格式定的是哪个？」
→ 上下文摘要：需求 2 条、进行中任务 3 个、最近反馈 1 条 —— 不用你复述
关键不在于它记住了多少，而在于你从来不需要复述。切换 session、隔一周、换一台机器（把项目目录带过去就行），
接续的成本是一次 dev_context_get。
它为什么不会「聊着聊着就丢了」
persona 写在上下文开头，回合一长就会被工具结果挤远。我们在真机会话里量到过：dev_context_get 在第 1 秒就调用了，
dev_request_capture 却拖到 +86 秒、第 40 次工具调用之后，dev_feedback_record 整轮没触发。
所以插件做的不只是一段提示词：
- 运行期提醒：通过
agent/pre-step，在第 1 步以及之后每 5 步往请求历史里追加一条带当前项目
真实记录计数的提醒（需求 2 · 任务 3 · 反馈 1 · 验证 1 · 完成 0），附带执行顺序。它只读
/.dsh-dev/，不写状态，读取失败原样放行，不会让回合挂掉。 - 原话优先：
rawQuote存的是你打的字，不是它总结的版本。失真从第一行就被拦住。 - 记录跟着项目走：
/.dsh-dev/*.jsonl，append-only，只追加不改写，git diff之外多一条可回滚的证据轴。 - 有界摘要：
dev_context_get只给项目目标、未完成任务、最近反馈 —— 不把半年历史一次性灌进上下文。
60 秒上手
- 装：
DSH「Add plugin」里搜 dsh-plugin-dev-workflow
或者：
plugin_manager install_bundle target=dsh-plugin-dev-workflow
本地开发时：plugin_manager install_bundle target=<本目录绝对路径>
- 新建会话，选 preset「研发助手 · Dev Assistant」。不要手写 profile 的
package.json或cordis.patch.yml。 - 用平常的话说想法。第一句话不需要格式，比如「我想把 X 做得更顺手一点，先看看现在什么样」。
第一次用最值得观察的一点：它会先问验收条件，再动手。如果你觉得它问得多，那是这套流程在起作用 ——
一个说不清「怎样算做完」的需求，最后一定会以「这不是我要的」收场。
工具箱
| 工具 | 干什么 |
|---|---|
dev_context_get |
读项目上下文、未完成任务与最近反馈（有界摘要） |
dev_request_capture |
保留用户原话与验收条件；缺验收时只做澄清登记，不自动开工 |
dev_request_close |
给需求终态：delivered（已交付）/ invalid（已作废）/ superseded（已被取代）；append-only 追加状态行，需求列不再陈列已终结需求 |
dev_feedback_record |
记录反馈原话与决策，不自动升级为长期规范 |
dev_task_plan |
建任务：步骤、依赖、风险、验收；破坏性范围可标 waiting-user |
dev_verify |
记录真实命令与退出码，exitCode 由调用方给，不接受伪造 succeeded |
dev_complete |
汇总完成内容、变更文件、证据、风险与未完成项；没有通过证据只能是 partial，没有你确认只能是 waiting-user |
dev_knowledge_promote |
只在你明确确认后沉淀偏好或规范，默认 proposed，可撤销 |
记录到底长什么样
本地 append-only JSONL。下面是脱敏示例，不是预置数据：
{"schemaVersion":1,"requestId":"req_7f21","rawQuote":"把登录页的错误提示改得更清楚","acceptance":["空密码显示字段级提示","错误提示不泄露账号是否存在"],"status":"captured"}
{"schemaVersion":1,"feedbackId":"fb_12ac","requestId":"req_7f21","rawQuote":"文案要短一些，但保留可操作建议","decision":"accept","category":"quality","status":"recorded"}
{"schemaVersion":1,"taskId":"task_91de","title":"更新登录错误提示","acceptance":["单元测试覆盖两种错误分支"],"status":"queued"}
{"schemaVersion":1,"verificationId":"verify_44aa","taskId":"task_91de","command":"npm test -- login","exitCode":0,"status":"passed"}
{"schemaVersion":1,"completionId":"completion_08c1","taskId":"task_91de","status":"succeeded","verificationRefs":["verify_44aa"]}
/.dsh-dev/
├── requests.jsonl 你亲口说的需求（原话 + 验收）
├── feedback.jsonl 你的每次反馈与决策
├── tasks.jsonl 任务、依赖、风险
├── verifications.jsonl 命令与退出码
├── completions.jsonl 收口总结
└── knowledge.jsonl 被确认过的偏好（默认只是候选）
纯文本、可 grep、可 git diff：想看就打开，想比就 diff，想接自己的脚本就随便接。
边界与隐私
- 全部在本地。没有账号、没有云端、没有遥测。
- 只追加：
dev_*工具不改写历史；dev_complete从不回写tasks.jsonl，「已完成」由completions.jsonl推导。 - 不越权：不跨项目读取、不自动装依赖、不自动
git commit、不自动npm publish。 - 别把
.dsh-dev/提交进 Git（本项目自己也在.gitignore里），也不要往里写密钥或客户资料。
它明确不做的事（说清楚，免得你按它没有的方式用它）：
| 不做 | 因为 |
|---|---|
| 多人协作 / 角色权限 / 代码评审 | 它是给一个人（或两三个人顺手用）的轻量流程 |
| 云同步、团队共享看板 | 记录是项目目录里的文件，跟着仓库走 |
| 自动提交、自动发布 | 交付的最后一步永远留给人和你的 2FA |
| 企业合规审计 | 它留证据，但不做审计系统 |
| 强制的多人流程治理 | 它靠人设和提醒约束 agent，不靠审批流 |
记录一多怎么办
一个跑半年的小项目会有几百条需求、上千条任务。看板不假设记录少：
| 维度 | 做法 | 为什么 |
|---|---|---|
| 已完成任务 | host 只返回最新 30 条，列头写 5/150，底部 显示更多 · 还有 145 条，点一次 +50 |
历史是无限增长的轴，必须服务端截断 |
| 需求 | 同上，默认 40，每次 +40 | 需求同样只增不减 |
| 待办 / 待确认 | 每列默认 20，显示更多 本地 +30，不重新请求 |
已经在响应里，本地切片就够 |
| 计数 | 顶部 chips 永远描述全量，列头才写「已显示/总数」 | 知道总量，也知道屏幕上只是一部分 |
| 反馈 | 每个需求/任务只挂最新一条，历史仍在 feedback.jsonl |
卡片看结论，历史留档 |
实测（合成数据 200 需求 / 300 任务 / 150 完成）：默认响应 70 KB，全量 155 KB，readBoard() 约 10 ms。
兼容性
- DSH：
>=0.2.1-rc.2 <0.3.0 - Node.js：
>=22.19.0 - 当前版本：
0.2.6
开发
node verify/smoke.mjs # 门禁：工具 + 提醒 + 看板 host/client
node verify/preview.mjs # 用真实记录离线渲染 docs/preview-board.png
node --check index.js client.js
npm pack --dry-run
发布记录与踩坑写在 docs/log/，每个版本一篇。
路线图
- [ ] 真实宿主执行器与验证证据绑定
- [ ] 完成任务自动更新状态
- [ ] 路径边界校验与敏感信息检测
- [ ] 干净 profile 安装测试与 CI
项目链接
- Repository: https://github.com/yuna78/dsh-plugin-dev-workflow
- Changelog: CHANGELOG.md
- Issues: https://github.com/yuna78/dsh-plugin-dev-workflow/issues
- npm: https://www.npmjs.com/package/dsh-plugin-dev-workflow
License
MIT
