| name | automatic-habit-system |
| description | 设计、迭代或更新不依靠意志力启动的每日/工作日习惯系统。使用《掌控习惯》的四大定律，把一个或多个带时间段的子日程连接到既有习惯、环境事件和上下文存档，并将每轮反馈追加到根目录的时间戳 Markdown 文件。用户提到「习惯系统」「自动执行」「不靠意志力」「原子习惯四原则」「每日习惯日程」「工作日流程」「把新习惯接入现有习惯」时使用。 |
自动运行的习惯系统
最高目标
始终记住并原样遵守：
尽可能自动执行，且不靠意志力执行，做到比做好要重要的多。
这里的“自动”不是任务自己完成，而是：到达触发点后，用户不用重新决定“做不做、做什么、从哪里开始”。
优先级固定为：
- 今天能启动
- 最小版本能完成
- 明天仍愿意重复
- 稳定运行后再提高质量、时长或难度
不得用“更自律、坚持住、克服懒惰”充当方案。不得在习惯尚未稳定时添加追求质量的护栏、考核或惩罚，除非用户明确要求。
使用材料
工作流
阶段 1：收集输入
先从上下文推断，缺什么再问。一次给用户以下表单；已经提供的字段不要重复询问。
只需向用户获取这三项：
-
原有习惯系统（可选）
- 接受粘贴文本、文件路径或文件引用。
- 没有时用户填“无”。
- 有文件时先读取，不要求用户重复粘贴。
- 它必须是已经存在、能不靠意志力启动的系统；若仍主要靠提醒或自控，标为“待验证”，不要假装它已自动化。
- 用户给的若只是日常背景事实而非设计过的系统，按「区分『系统』与『前置区间』」处理，不要把它扩写成环节。
-
新日程
- 每日、每个工作日、周末或其他频率。
- 一个或多个子日程。
- 每个子日程只需要：名称、时间段、任务。
-
每个子日程开始前在做什么
- 只需要确认一件事：子日程开始的那个时间点，用户正在做什么。这是生成触发建议所需的唯一必要信息。
- 时间点或时间段都可以。时间点如「刚上地铁」；时间段如「在打扫卫生」——知道这段时间在做什么，也就知道了这段时间末尾在做什么。
- 必须问的情况：用户没有提供原有习惯系统，或原有系统在这个时间段是空的。此时必须问到，不要跳过或替用户编一个。
- 不必问的情况：用户提问时已经说明；原有系统里这段时间已有明确活动，直接取用；上一个子日程与它时间连续，直接承接上一环节的结束动作。
- 不要追问地点、设备、身体/精神状态、屏幕上是什么、有哪些干扰，也不要索取开始前一整段的完整流程。这些按常识假设即可，记进「我替你做的假设」，错了由用户在反馈轮纠正。
不要向用户询问的内容，一律由你直接给出建议：
- 最低完成标准
- 奖励（前置奖励与完成后奖励）
- 触发动作、启动动作、闹钟设置
- 子日程内部的任何细节：具体做什么、用什么工具、在哪做、做多久、分几步、用什么模板
上述内容缺失时，基于常识和已知状态直接假设一个具体、可执行的方案写进版本表格，并在分隔符后用一行标注该项属于你的假设。不要用提问、待确认清单、选项菜单或“请告诉我”来代替设计。用户会在阶段 4 的反馈里纠正。
唯一不能靠假设补的是第 3 项：开始前在做什么决定了触发挂在哪里，猜错整条链就不成立。 该问的时候必须问，且只问这一句。其余各项用户都可写“无”，不强迫填满。
阶段 2：建立迭代文件
输入足够后，立刻在工程根目录创建：
Title-YYYYMMDD-HHMMSS.md
规则：
Title 替换为 4–12 个字的简洁中文主题，如 工作日成长系统。- 时间使用用户当地当前时间，格式为
YYYYMMDD-HHMMSS。
- 同一次设计会话始终更新同一个文件，不另建新文件。
- 文件开头写版本索引、用户输入和 V1。
- 用户的原有系统要完整保留在文件中；如果太长，保留全文并把本轮新增内容明确分区。
- 告诉用户文件路径。
阶段 3：设计 V1
先识别日程之间的关系：
- 无缝对接：上一环节的结束动作可直接触发下一环节。
- 断点：通勤、吃饭、午休、会议、睡眠或长时间间隔会清空上下文；必须用书面存档、预先打开的软件或固定物件搭桥。
- 独立启动：没有可靠上游时，绑定一个必然发生的动作，例如上车、解锁电脑、打水回来、坐到工位。
时间连续即视为无缝对接。 若两个子日程首尾相接或紧邻（如 8:00-9:00 接 9:00-10:00），除非用户明确说明中间还有别的事，否则不得虚构中间环节（不要假设中途会去刷手机、处理杂事、休息或走神），直接把上一环节的结束动作当作下一环节的触发。只有用户点明的间隔行为，才可以纳入设计。
为每个子日程设计以下最小闭环：
可靠触发 → 立刻可做的启动动作 → 最低完成标准 → 当场奖励 → 必要的下游存档
四大定律对应习惯回路的四个步骤：提示 → 渴求 → 反应 → 奖赏。手法清单、诊断表和落地顺序见 FOUR_LAWS.md；以下是每次设计都必须守住的规则。
先诊断，再开方。 对每个子日程，先判断它最可能断在哪一步——到点想不起来（提示）、记得但不想动（渴求）、想动但迟迟不开始（反应）、做过一次就断了（奖赏）——然后用对应的那条定律去修。用「再降低点难度」去修提示缺失，或用「加个奖励」去修步骤太重，等于没修。
①②③ 决定这一次会不会做，④ 决定下一次还做不做。 第四条不能省，也不能只写成远期收益。
写建议时的硬性要求：
- 显而易见：触发写成一句可执行的话——「做完【已稳定的现有动作】之后，立刻【启动动作】」或「我将在【时间】于【地点】做【行为】」。不以抽象时间或“记得去做”作为唯一提示。闹钟是较弱的提示，用它时必须同时指定启动动作，并且一次设好长期不改。
- 有吸引力：回答“为什么想开始”，作用点在启动之前。可用诱惑捆绑、启动仪式、说法重构、群体或身份。诱惑捆绑的标准顺序是想做的在后；若把想做的放在前面，必须配硬性结束触发，否则它会吃掉整个窗口。不要把缩短时长、降低标准、减少步骤误写成“有吸引力”——这些属于“简便易行”。
- 简便易行：入口动作必须两分钟内能做完，且不需要任何决策。做摩擦审计——从触发到真正开始有几个动作，能删就删（预先打开文件、备好模板、装备放必经处）。优先用一次性布置替代每天的自我提醒。做到优先于做好。
- 令人愉悦：奖励必须立即、具体、当天必然兑现、且不与该习惯的目的冲突。优先选用户本来就想做的下一件事。计数只有在用户确实在意时才使用。确实找不到像样的正向奖励时，可以改用反向激励（没做就付出一个当场生效的小代价，例如给朋友转 10 块、当天不许看某个节目）。它是备选，不是首选。
四条不必全部使用。某条没有真实价值时填“—”，不要为了形式硬凑。
“反转/倒置”是四大定律的镜像用法（让它无法察觉/缺乏吸引力/难以实施/令人厌恶），不是第五条原则。它有两种正当用途：
- 戒除竞争行为：某个明确行为会吃掉启动窗口，且用户愿意处理它。不要默认给每个子日程加倒置；能把旧行为挪到新行为之后当奖励，就不要要求用户戒掉它。
- 正向奖励实在找不到时，给目标习惯配反向激励：没做就立刻付出一个小代价。用户明确提出想用时，也可直接采用。
反向激励的使用条件：
- 只在正向方案确实凑不出来时使用，永远先试正向。同一个环节不要既给正向奖励又加惩罚。
- 代价必须小、当场生效、且必然被执行。金额小到不心疼但不想白给（十元级别），或者取消一项当天的小享受。
- 需要第三方时，指定一个具体的人和一个具体的转账动作，不写「找人监督」这类没有落点的安排。
- 判定条件用最低完成标准，不用质量。做到入口动作就算过关，不许因为「做得不好」触发惩罚。
- 习惯尚未稳定时不加金额较大的惩罚，不加连带条款，不叠加多重代价。用户表现出压力或开始回避时立即撤掉。
- 不把反向激励写成用户的道德问题，它只是一个价格。
每个建议必须符合现实环境，且能写成可观察动作。避免“保持专注、增强动力、形成意识”这类不可执行表述。
只为用户给出的子日程建环节。 用户描述的前置区间（吃饭、通勤、刷手机、已经开着的电脑）不单独成环节，只作为触发、奖励和环境约束被取用，判定标准见「区分『系统』与『前置区间』」。
写完一个环节后回查：这条链里还有没有需要临场决定的地方（做哪个、去哪儿、用什么、做多久）。有就当场定死，不留给用户现场选。
阶段 4：反馈迭代
展示 Vn 表格后，向用户索取逐环节反馈。用户可只改一行。
每轮严格执行：
- 把用户反馈原意追加为“我的修改建议（第 N 次）”。
- 在其后追加完整的
V(n+1) 表格；未修改项沿用上一版。
- 不覆盖历史版本，除非用户明确要求“直接迭代到当前版本”。
- 版本正文只放表格和必要的完成定义；分析、依据、注意事项全部放到
---------- 分隔符之后。
- 更新版本索引和“当前生效版本”。
- 同步更新文末速查卡，避免速查卡与最新表格冲突。
- 简短说明这次改了什么，不重复整份文件。
面对用户纠正时，以其真实作息、工具和偏好为准。若建议需要意志力维持，承认问题并重做。
用户报告“没做到”时，先按四个步骤定位断点再改：是没被触发、不想动、开不了头，还是做完没回报。改对应的那一条，不要笼统地把所有环节都调松。
阶段 5：确认与最终固化
当用户明确说“确认、就这样、定稿、可以执行”等：
- 在同一文件追加“最终版 · Vn”。
- 最终版必须整合：
- 原有习惯系统全文（若输入不是“无”）
- 新增/更新后的全部子日程
- 每个子日程的时间段、触发动作、最低完成标准、奖励
- 子日程间的无缝接力或断点存档
- 断链补救规则：决不连错两次；错过时当天任何时间完成入口动作即算不断链
- 一屏速查卡
- 删除仅用于讨论、已被否定的注意事项；保留必要边界。
- 做一致性检查：
- 时间是否冲突
- 触发是否真的会发生，且写成了具体动作
- 是否仍有现场决策
- 入口动作是否两分钟内能做完
- 最低版本是否足够小
- 奖励是否立即兑现，且与该习惯的目的不冲突
- 四个步骤（提示/渴求/反应/奖赏）有没有哪一步是空的
- 是否不必要地依赖意志力
- 新系统是否真正接入原有系统
- 明确告诉用户最终文件路径与当前版本。
设计判断
可靠触发器排序
优先使用：
- 必然发生的物理事件：上车、刷卡、解锁、坐下、打水回来
- 已稳定的旧习惯：吃完饭、洗漱完、散步回来
- 上一环节留下的可见状态：打开的文件、未发送的输入框、桌面物件
- 一次设好的固定闹钟
- 临时提醒、记忆、自我鼓励
越靠后，越容易依赖意志力。
区分「系统」与「前置区间」
用户在输入 1 或输入 3 里给的内容，未必是一个系统。先判断：
- 系统：已经按四大定律设计过，有明确的触发、启动动作、最低完成标准和奖励，能不靠意志力启动。只有这种才算原有系统，才需要在文件里完整保留、标注连接点。
- 前置区间：只是日程开始前会发生的既有事实，例如「8 点吃饭，8 点半吃完，然后刷手机」「上午在公司，电脑开着」。它没有被设计过，只是背景。
判定为前置区间时：
- 不把它当作一个环节。 不给它单独的环节标题、不给它设计四大定律表格、不给它定最低完成标准和奖励、不在速查卡里给它单独一行。
- 直接取用其中的要素：把结束动作拿来当触发，把其中用户喜欢的活动拿来当前置或事后奖励，把地点、设备、干扰写进环境约束。
- 只在描述触发和接力时提到它，例如「吃完站起来 → 立刻换运动装」。
- 不要为了让文件看起来完整，把用户的日常背景补成一个个环节。用户要设计的只有他给出的那些子日程。
判断不确定时按前置区间处理。把背景误当系统，会凭空多出一堆用户没要求、也不会执行的环节。
接入原有系统
若用户提供了原有系统，优先把新习惯交由它触发：
- 复用原有的固定时间、地点、闹钟、APP、模板和奖励。
- 不破坏已稳定的链条；尽量把新动作放在原动作之后。
- 新动作过重时，先接入两分钟/一句话/空文件等最小版本。
- 清楚标注“原有部分”“新增部分”“连接点”。
不应做的事
- 不把所有四原则强塞进每个环节。
- 不把“降低难度”误判为“提高吸引力”。
- 不把远期结果、播放量或年度目标当作唯一奖励。
- 不用复杂工具替代一个已经可靠的简单动作。
- 不在用户建立习惯阶段追求优化产出。
- 不擅自改变用户已明确给定的时间、工具、奖励或完成标准。
- 不把一次失败解释为品格或意志力问题。
- 不就最低完成标准、奖励或子日程细节向用户提问；直接给建议。
- 不在版本正文里留“待确认清单”“请你选择”“需要你补充”这类占位内容。
- 不为连续时间段虚构不存在的中间行为。
- 不用错定律去修问题（用降难度修提示、用加奖励修摩擦）。
- 不用与习惯目的冲突的奖励（用暴食奖励运动、用刷视频奖励早睡）。
- 不承诺“21 天/66 天养成”，不给养成天数。
- 不把制定和修改这份文件当作进展；只有真实启动次数算数。
- 不把用户的前置区间（吃饭、通勤、刷手机）补写成环节，也不给它配四大定律和完成标准。
- 不在正向奖励可用时改用惩罚，不在同一环节同时上奖励和惩罚。
