| name | continuous-work |
| description | 持续工作模式——stop hook 触发或客户提到时启用。入口动作是先做一次大抬头（按 .boss/principles/lookup-beats.md 大抬头扫描），然后按 9 条硬约束（代码质量、工程质量、渐进式披露、遇阻深挖、不确定求证、单点不停摆、先抄后造、精益求精、task 最低规划深度）和「看得更多 / 做得更多」选下一步。配套 .ai/continuous.yaml 配置和三家 CLI（Codex/Claude/OpenCode）stop hook 安装器。 |
持续工作模式
stop hook、客户或 .ai/continuous.yaml 要求"按持续工作模式执行"时，先读本文件，再决定是否停止。
持续工作模式不是一种业务工作路径，而是停止前的行为约束。
本 skill 假定 owner 主入口的姿态前提已经生效，并已读完 .boss/PROFILE.md、.boss/CONVENTIONS.md、.boss/principles/。
入口动作：先做一次大抬头
进入持续工作模式 = 先做一次大抬头（见 .boss/principles/lookup-beats.md 大抬头扫描），再走本规程。
stop hook 触发 = AI 想停了 = 它觉得做完一段了——这正是大抬头时刻。先按大抬头流程从上到下扫一遍 PROFILE → requirements → Roadmap → architecture → tasks INDEX，用主理人三视角判断现状，再进入下面的硬约束和"看得更多/做得更多"。
不要跳过大抬头直接看硬约束——抬头是上下文重建，后面的判断和动作都建立在抬头看到的现状上。
核心要做的事
核心不是单纯"不停"，而是：
- 先完成未结束的东西：active task、active Roadmap 条目、未验证、未提交、未清理工作区。
- 看得更多：扫需求、架构、代码、文档、测试、用户流程、视觉品质、竞品、竞品源码、工作区状态。
- 想得更多：判断风险、机会、质量缺口、体验缺口、视觉缺口、用户摩擦、工程债、文档偏差。
- 做得更多：选择一个安全、有价值、可验证的下一步继续推进。
硬约束
执行 AI 在每轮开始前和产生任何计划时，必须遵守以下硬约束。这些不是建议——越过任何一条直接进入"判断种子"或"看得更多"属于违规。
1. 每轮开始前必须检查代码质量
不能跳过，不能假定上一轮结束时是干净的。检查项：
- 当前工作区是否干净（
git status）。
- 如果不干净，剩余改动是否有归属、有原因、有下一步？若没有，本轮第一动作是清理或记录，不能带着脏工作区开始新计划。
- 本轮会碰到的文件是否触发了 owner-execute 工程治理里的任一换轨信号（单文件超 500 行、承担多类职责、临时产物污染根目录、复制粘贴等）。
- 本轮计划的新增是否会让已有大文件继续膨胀、让复制粘贴扩散、或让临时方案变正式。
- 本轮改过或新增的 UI 必须视觉走查一遍：间距是否一致、对齐是否准确、配色是否统一、字体层级是否清楚、交互状态（hover/active/disabled/loading/empty/error）是否都有反馈。
如果检查发现质量缺口，缺口本身优先于功能新增——要么本轮修，要么创建工程化条目并标记阻塞原因。
如果当前存在 active Roadmap，本轮必须读 owner-execute 的 Roadmap 质量指南 和 SKILL.md 中的「阶段大抬头」段；不能只靠工程自检、忽略 Roadmap 层面的产品质量维度。
2. 产生的任何计划必须考虑工程质量维度
"计划"包括 task 执行方案、Roadmap 条目拆分、写代码前的思路、以及"看得更多"后的下一步选择。每个计划至少回答：
- 结构：新代码放哪里？是独立模块还是内联？引用 owner-execute 的新业务逻辑放置做出选择。
- 边界：改动范围和影响面是否清楚？测试和生产代码的边界是否守住？
- 复杂度：这次改动是降低还是增加系统复杂度？有没有因为"最小 diff"而忽略"最小认知负担"？
- 正式性：如果是正式产品，是否满足 owner-execute 的正式产品阶段标准？
如果计划没有可辨识的工程考量（即计划读起来只讲功能、不讲结构），不能开工。
3. 计划必须遵循渐进式披露原则
引用 .boss/principles/information-architecture.md 的核心规则，每条计划必须：
- 先写整体地图（目标、阶段、当前大致状态），再展开执行步骤。
- 先分组（按能力/子系统/风险分组），再在组内罗列条目。禁止把不同类型、不同层级的事摊成一长串。
- 先结论再证据：先说做什么、为什么，再说怎么做。
- 先结构再实现：先说放哪里、边界在哪，再写具体代码。
如果一个 plan 读起来像"把所有要做的事按想到的顺序列出来"，还没有经过信息组织，退回重组。
4. 遇阻必须先深挖到底
报告"缺 X，不能继续"之前，必须先穷尽本地和网络手段：
- 检查环境变量（
env、.env、.env.local、shell profile）。
- 检查项目配置文件、CI/CD 变量、密钥管理工具。
- 检查文档（
.boss/wiki/、README、CONVENTIONS）是否有凭证位置说明。
- 网络搜索：搜索相关工具/框架/平台的凭证获取方式、免费额度、替代 provider、社区常见绕过方案；搜索是否有公开文档或 issue 讨论过同类阻塞。
- 检查是否可以用替代方案绕过（本地 mock、离线模式、其他 provider、跳过非核心验收项继续推进其他条目）。
只有穷尽以上仍无解时，才能报告阻塞。报告必须包含：已搜索的位置列表、已尝试的替代方案、为什么不可绕过。禁止只写一句"缺 X，不能继续"。
5. 不确定时必须求证——不能幻想，可以上网查、可以自己测
"遇阻"是知道缺什么。"遇疑"更隐蔽也更危险——自以为知道，实际上在编造。不确定时不求证就动手，比承认"不知道"危害更大，因为错误会传导放大。
- 文档提到"参考某项目/工具/方案"——这不是话术，是命令。必须先去看那个东西是什么、怎么做的。网络搜索是基本手段，不是加分项。没看过就没有资格引用，更没有资格评价。
- 能自己测试的必须测：写最小复现、跑真实流程、验证假设。悬而未决的问题不能靠"应该没问题"放行。
- 查完测完仍不确定，带着已做的功课和备选方案问客户。宁可交"我查了这些、测了这些、还缺 X"的诚实缺口，不交"我自己填了"的虚假完成。
- 求证方向以用户需求为锚点：查什么、测什么、怎么选方案，永远以"这对用户意味着什么"为判断基准，不是以"技术上好不好做"或"我熟不熟"。
6. 单点阻塞不能全局停摆
当前 Roadmap 或 task 被确认阻塞后，不能反复报告同一个阻塞然后停摆。必须：
- 先标记阻塞原因和等待条件到 Roadmap/task。
- 然后扫描全局：同一 Roadmap 下是否有其他安全条目？是否有其他 active Roadmap？是否有工程债待清理？是否有文档偏差待修正？是否有
.boss/ 规范收敛待做？
- 选择最近、最安全、最有价值的可推进事项继续执行。
7. 先抄后造——写功能前必须先找轮子
实现任何非平凡功能（认证、加密、权限、文件处理、网络请求、状态管理、UI 复杂组件等）之前，禁止从零手写。必须先：
- 检查当前依赖里是否已有现成功能（读了整个
package.json/Cargo.toml/requirements.txt 等再做判断，不能想当然说"应该没有"）。
- 搜索成熟开源项目中同类功能的实现源码，读他们的做法——边界条件怎么处理的、错误分支怎么覆盖的、接口怎么设计的。
- 搜索是否有轻量、单一职责的库可以直接用或参考其源码结构。
决策顺序：
- 已有依赖里有 → 直接用。
- 有成熟轻量库 → 引入。
- 有开源项目的参考实现 → 抄源码结构和关键逻辑，适配当前项目接口，保留原作者的边界处理。
- 以上都没有 → 最后才能自己写，且必须在注释里说明"未找到参考实现"。
反例： 自己写一个 OAuth 流程、自己写一个密码哈希、自己写一个文件上传分片——这些领域有几十个成熟实现，自己写必然漏边界条件、出安全漏洞。
这条规则适用于代码层面。如果该功能本身就是产品核心差异化能力（不是通用轮子），直接走 3 或 4，但必须明确写清"非通用轮子，核心差异化"的判断依据。
8. 精益求精——不止完成，要完成得更好
执行每一个 task、推进每一条 Roadmap 条目时，姿态不是"把需求文档里的 checkbox 勾掉"，而是"这件事怎么做才算真正做好"。
- 每完成一个功能点，反问一句：这样做就够了吗？ 需求文档写的是下限，不是上限。用户实际用的时候会不会还有一步没走通？
- 时刻区分两类需求：客户说的（钉子，定方向）和用户真正需要的（网，完整体验）。完成客户提的 A 之后，检查用户从 A 到 B 的整条链路是否顺畅。
- 关注细节摩擦：一个多余的点击、一个没说清楚的错误提示、一个不合理的默认值——这些不在需求文档里，但用户会因此觉得产品"不好用"。
- 每个 task 收尾时，不只汇报"完成了什么"，附一句"我觉得还有哪里可以更好"——哪怕本轮不修，记下来留给下一轮或下一个阶段的需求与质量回顾。
如果一个 task 从头到尾没有产生任何"还可以更好"的想法，说明执行姿态只在交差，不在做产品。
9. task 必须达到最低规划深度和体量
task 是有规划、有思想、有深度的工作单元，不是原子化编辑的包装纸。把"从文件 A 提取 12 行到文件 B"当作一个独立 task，是抽象层级太低——这不是在精益求精，是在敷衍了事。
最低体量：一个 task 至少包含多个关联步骤，交付可感知的价值。同类小改动（如同一模块下的多次拆分、同一功能边界下的多个边界覆盖、同一轮验收的多个检查点）必须合并在一个 task 内，不能拆成碎渣。
最低规划深度：执行方案不能只写一步。必须体现：先做什么、后做什么、为什么这个顺序、风险在哪。如果执行方案只能写一步，说明这不是 task，是 task 内部的一个步骤。
判断是否太碎：
- 回头看本 task 的 commit diff，改动的文件和行数是否太少？
- 如果能用一句话不加"和"字描述完本 task 做了什么，说明太碎。
- 如果本 task 的 task 文档比代码改动还长，说明太碎。
同类合并：本轮的多个小改动如果是同一类目标（如"降低某文件的负担"），应该是一个 task，不是每个改动一个 task。
反例：一个 commit 配一个 task，commit message 和 task 标题几乎一样，task 文档里的执行记录时间戳全部相同——这不是在执行 task，是在给 commit 补文书。
判断种子
参考以下线索，思考是否能做得更多。
- 当前 task 是否完成、验证、提交、归档。
- 当前 Roadmap 是否还有安全可推进条目。
- 工作区是否干净或剩余改动是否有归属。
- 文档是否和事实一致。
- 是否有明显质量缺口可安全修复。
- 是否需要创建新的 task 或 Roadmap。
- 当前阶段是否刚刚完成？若是，是否已执行需求与质量回顾，不舒服的条目是否已列入 planned？
看得更多
当前 task 或 Roadmap 阶段看似完成时，不要立刻停。先从这些方向看一圈。
方向是地图，不是操作方法。 每个方向的"怎么看""怎么判""产出什么"有对应的巡检方法，见 owner-execute 的工程巡检方法论。对着方向卡住时，翻到对应的巡检条目，按操作步骤执行。
向内看
- 需求真的满足了吗？有没有需求从来没被实现过？
- 代码有没有腐烂点、重复模式、边界混乱、命名误导？
- 错误态、空状态、加载态、极端输入覆盖了吗？
- 测试诚实吗？是否只验证"不报错"，没有验证真实行为？
- 文档和代码对得上吗？架构决策有没有被绕开？
- 真实流程跑起来是否顺，性能、日志、可观测性是否够用？
- 权限、输入校验、敏感数据处理有没有明显风险？
向外看
- 类似工具或竞品怎么做？差距和机会在哪？
- 依赖生态、框架、组件库有没有更合适的新做法？
- 借鉴竞品时，独立评审人并排比较会选谁？
精益看
从用户视角出发，纵深审视当前产品到底够不够好。不是走马观花——必须按顺序走完以下两层，每一层都要产出具体的"不够好"条目或确认"这一层没发现问题"。
第一层：用户视角审视
忘掉需求文档，以真实用户的身份走一遍完整流程。问自己：
- 我现在想完成一件事，我能自己找到入口吗？中间有没有卡住或者犹豫？
- 做完这件事之后，我得到了什么反馈？这个反馈够清楚吗？
- 有没有某个时刻我觉得"这不对"或者"这应该有但找不到"？
- 加载中、出错时、数据为空时——这些时刻的体验和正常状态一样被认真对待了吗？
- 如果我是第一次用这个产品，我会在哪个页面被劝退？
把不舒服的点记下来。如果这一层已经发现了明确的改进方向，直接产出条目，不走第二层。
第二层：竞品纵深对比
第一层走完仍觉得"好像还行，但讲不出哪里不好"，或者觉得"应该还有更好的做法但我想不出来"时——进入竞品纵深对比：
- 搜索 2–3 个解决同类问题的产品，不是看官网和特性列表，是实际使用或用截图/视频走一遍他们的主路径。
- 找出三件事：他们哪里做得比我们好、哪里做得比我们差、哪些做法完全不一样但值得想一想。
- 看他们的源码：如果竞品是开源的，找到和我们当前功能对应的模块或文件，读他们的实现。关注：
- 边界条件他们覆盖了哪些我们没覆盖的？
- 错误处理他们用了什么模式？
- 接口和数据结构的设计比我们好在哪里？
- 有没有我们可以直接参考或适配的代码结构和逻辑？
产出
两层走完后，必须产出：发现的具体问题列表（附证据——截图、源码片段、竞品对比），按"用户能感知到的改善"排优先级。能修的小问题本轮直接修；需要设计讨论的创建 task 或追加到 Roadmap planned 条目。
用眼看
视觉质量不是"好看"，是产品完整性的硬指标。用户对产品的信任有一半来自视觉——功能到位但看着糙，用户会觉得不可靠。
产品视觉
- 间距和网格：同类元素间距是否一致？有没有 1px 偏移、没对齐、贴边没留白？
- 配色：是否用了未定义的灰色/蓝色？暗色模式是否大面积缺失？对比度是否够读？
- 字体：层级是否清楚（标题/正文/辅助文字有明显差异）？字号和行高是否舒适？是否混用了未指定的字体？
- 交互状态反馈：hover、active、disabled、focus ring 是否都有？动画过渡是否生硬或缺失？
- 空状态和错误态：是不是比正常状态差很多、像忘了设计？
信息呈现
- 信息密度是否合适？关键信息是否一眼能看到？还是被埋在一堆次要信息里？
- 层级是否清楚？区块之间留白是否足够区分"不同组"和"同一组内"？
- 长页面是否有视觉节奏？还是从头到尾一个密度让人不想读？
交付物体面
- 文档里的截图是否干净（无多余窗口、无脏数据、分辨率够）？
- 对外演示是否整洁（浏览器干净、无个人书签栏、无多余 tab）？
往深看
- 客户真正要解决的问题是什么？当前实现是否只满足了表层需求？
- 用户完成主路径时有什么摩擦？
- 哪些取舍是临时的，是否需要退出条件？
回头看
- 上一个 task/Roadmap 有什么踩坑经验？
- 哪些决策回头看是对的，哪些需要调整？
- 反复出现的问题是否应该沉淀成规则、模板、指南或工具？
- 本轮是否犯了错、花了较长时间才定位解决？小体量的教训（一行规则、一个命令、一个配置项）沉淀到 CONVENTIONS.md；大体量的经验（需要解释为什么、有多个关联点、或值得独立查阅）沉淀到 wiki/。
元层面看
- owner 系列 skill 有没有覆盖不到的重复模式？
- 开发体验、构建、错误信息、工具链有没有摩擦？
- 当前
.boss 文档是否符合最新规范，是否需要规范收敛？
做得更多
当前工作阻塞或完成、且无直接可推进条目时，不空转。以下是安全、有价值、不依赖外部授权的主动推进方向。
工程巡检（默认动作）
空转时的第一选择不是停下来，是巡检。
两阶段流程：先想再干。第一阶段只侦查、只记录、不修改代码；第二阶段从发现清单里挑一项执行。
第一阶段：巡检
- 从 owner-execute 的 工程巡检方法论 巡检目录里选一个方向。选法：上次巡了哪个？换个没巡过的。如果 6 个方向都巡过一轮且距首巡超过 5 轮 → 可以复巡。
- 按该方向的"操作步骤"执行——读文件、跑命令、对比判断。
- 产出发现清单：每条发现必须有严重程度（高/中/低）和建议动作（修/建 task/讨论/入库）。按"用户能感知的改善"排优先级。
- 顺手修项：改一行配置、补一个文档条目、删一段死代码——这类单个动作能完成的低风险项直接修掉再记录，不用建 task。
第二阶段：执行
- 从发现清单里挑优先级最高的条目开工。创建 task 或直接修，按 owner-execute Task 执行或 工程治理 判断。
巡检纪律：
- 巡检是侦查，不是改造。不要在巡检过程中直接重构代码。
- 不允许输出"没发现问题"。如果真没发现，写清楚巡了哪个方向、读了哪些文件、用了什么判断标准——让过程可被审计。
- 发现清单要存活下来——记在 task 里或 wiki 里，下次空转时继续消化，不能巡完就扔。
视觉整饬
功能和探索都没直接推进项时，回头打磨已有 UI 的视觉质量。这是最容易被跳过的环节，也是对用户信任影响最大的环节之一。
- 逐个页面做视觉走查：按"用眼看"的检查项过一遍，标记不舒服的点。
- 修低级问题：对齐、间距、配色偏差、缺失的交互态——这些通常改动小、影响大。
- 高级问题（信息架构调整、全局主题不一致、需要重设计的页面）不直接动手，创建 task 或 Roadmap 条目，附具体问题描述和截图。
- 整饬完成后跑一遍主路径，确认没引入视觉回归。
前瞻性探索
以现有需求为锚点，主动扩展视野，发现缺口和机会。
流程：
- 重新打开需求文档，确认用户目标、场景和验收标准。
- 网络搜索竞品：找到 2–3 个解决同类问题的工具/产品/库，了解它们做了什么、怎么做的、用户评价如何。
- 并排对比：对照需求文档和竞品，找出当前实现缺失的能力、体验差距、或者竞品做了但需求没覆盖到的东西。
- 写下判断：哪些缺口值得做（影响力大、成本合理、符合产品方向），哪些不值得做（过度工程、偏离核心场景），每条附一句话理由。
- 输出结构化文档：不要写成长篇大论。按"缺口 → 竞品证据 → 建议优先级 → 理由"分组，放在
.boss/wiki/competitive-gap-analysis.md 或单独文件。
- 回链到 Roadmap：如果分析结果是明确的、有价值的功能缺口，创建新的 Roadmap 或在现有 Roadmap 当前阶段追加 planned 条目，附文档链接。
安全边界：
- 只分析、只记录、只建 Roadmap 条目——不写实现代码，不修改产品代码。
- 产出是可 review 的文档和 Roadmap 条目，客户可以随时驳回或调整。
- 如果分析过程中发现需要客户拍板的大方向问题（例如"竞品走的是完全不同的产品路线"），把问题写清楚，不擅自改产品方向。
安装与配置
只有在编写、调整 .ai/continuous.yaml prompt 时，才读 持续工作模式 prompt 接入说明。
只有客户要求安装、更新、排查 stop hook 时，才读 持续工作模式安装手册。
安装器：
node tools/install-stop-hooks.mjs
安装命令和三家实现细节只在安装手册里维护。不要把长期 Roadmap、进度快照或抽象解释塞进持续工作模式 prompt；prompt 只负责唤起本 skill，具体行为由本文承载，长期状态仍以 .boss/ 文档为准。
