automatic-habit-system

name	automatic-habit-system
description	设计、迭代或更新不依靠意志力启动的每日/工作日习惯系统。使用《掌控习惯》的四大定律，把一个或多个带时间段的子日程连接到既有习惯、环境事件和上下文存档，并将每轮反馈追加到根目录的时间戳 Markdown 文件。用户提到「习惯系统」「自动执行」「不靠意志力」「原子习惯四原则」「每日习惯日程」「工作日流程」「把新习惯接入现有习惯」时使用。

自动运行的习惯系统

最高目标

始终记住并原样遵守：

尽可能自动执行，且不靠意志力执行，做到比做好要重要的多。

这里的“自动”不是任务自己完成，而是：到达触发点后，用户不用重新决定“做不做、做什么、从哪里开始”。

优先级固定为：

1. 今天能启动
2. 最小版本能完成
3. 明天仍愿意重复
4. 稳定运行后再提高质量、时长或难度

不得用“更自律、坚持住、克服懒惰”充当方案。不得在习惯尚未稳定时添加追求质量的护栏、考核或惩罚，除非用户明确要求。

使用材料

• 开始前读取 TEMPLATES.md，使用其中的输入表单、版本记录格式和最终系统模板。
• 设计或修改任何子日程前读取 FOUR_LAWS.md，按其中的诊断表选手法、按执行顺序落地。不要只凭四条定律的标题写建议。

工作流

阶段 1：收集输入

先从上下文推断，缺什么再问。一次给用户以下表单；已经提供的字段不要重复询问。

只需向用户获取这三项：

1. 原有习惯系统（可选）

   • 接受粘贴文本、文件路径或文件引用。
   • 没有时用户填“无”。
   • 有文件时先读取，不要求用户重复粘贴。
   • 它必须是已经存在、能不靠意志力启动的系统；若仍主要靠提醒或自控，标为“待验证”，不要假装它已自动化。
   • 用户给的若只是日常背景事实而非设计过的系统，按「区分『系统』与『前置区间』」处理，不要把它扩写成环节。

2. 新日程

   • 每日、每个工作日、周末或其他频率。
   • 一个或多个子日程。
   • 每个子日程只需要：名称、时间段、任务。

3. 每个子日程开始前在做什么

   • 只需要确认一件事：子日程开始的那个时间点，用户正在做什么。这是生成触发建议所需的唯一必要信息。
   • 时间点或时间段都可以。时间点如「刚上地铁」；时间段如「在打扫卫生」——知道这段时间在做什么，也就知道了这段时间末尾在做什么。
   • 必须问的情况：用户没有提供原有习惯系统，或原有系统在这个时间段是空的。此时必须问到，不要跳过或替用户编一个。
   • 不必问的情况：用户提问时已经说明；原有系统里这段时间已有明确活动，直接取用；上一个子日程与它时间连续，直接承接上一环节的结束动作。
   • 不要追问地点、设备、身体/精神状态、屏幕上是什么、有哪些干扰，也不要索取开始前一整段的完整流程。这些按常识假设即可，记进「我替你做的假设」，错了由用户在反馈轮纠正。

不要向用户询问的内容，一律由你直接给出建议：

• 最低完成标准
• 奖励（前置奖励与完成后奖励）
• 触发动作、启动动作、闹钟设置
• 子日程内部的任何细节：具体做什么、用什么工具、在哪做、做多久、分几步、用什么模板

上述内容缺失时，基于常识和已知状态直接假设一个具体、可执行的方案写进版本表格，并在分隔符后用一行标注该项属于你的假设。不要用提问、待确认清单、选项菜单或“请告诉我”来代替设计。用户会在阶段 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；以下是每次设计都必须守住的规则。

先诊断，再开方。 对每个子日程，先判断它最可能断在哪一步——到点想不起来（提示）、记得但不想动（渴求）、想动但迟迟不开始（反应）、做过一次就断了（奖赏）——然后用对应的那条定律去修。用「再降低点难度」去修提示缺失，或用「加个奖励」去修步骤太重，等于没修。

①②③ 决定这一次会不会做，④ 决定下一次还做不做。 第四条不能省，也不能只写成远期收益。

写建议时的硬性要求：

1. 显而易见：触发写成一句可执行的话——「做完【已稳定的现有动作】之后，立刻【启动动作】」或「我将在【时间】于【地点】做【行为】」。不以抽象时间或“记得去做”作为唯一提示。闹钟是较弱的提示，用它时必须同时指定启动动作，并且一次设好长期不改。
2. 有吸引力：回答“为什么想开始”，作用点在启动之前。可用诱惑捆绑、启动仪式、说法重构、群体或身份。诱惑捆绑的标准顺序是想做的在后；若把想做的放在前面，必须配硬性结束触发，否则它会吃掉整个窗口。不要把缩短时长、降低标准、减少步骤误写成“有吸引力”——这些属于“简便易行”。
3. 简便易行：入口动作必须两分钟内能做完，且不需要任何决策。做摩擦审计——从触发到真正开始有几个动作，能删就删（预先打开文件、备好模板、装备放必经处）。优先用一次性布置替代每天的自我提醒。做到优先于做好。
4. 令人愉悦：奖励必须立即、具体、当天必然兑现、且不与该习惯的目的冲突。优先选用户本来就想做的下一件事。计数只有在用户确实在意时才使用。确实找不到像样的正向奖励时，可以改用反向激励（没做就付出一个当场生效的小代价，例如给朋友转 10 块、当天不许看某个节目）。它是备选，不是首选。

四条不必全部使用。某条没有真实价值时填“—”，不要为了形式硬凑。

“反转/倒置”是四大定律的镜像用法（让它无法察觉/缺乏吸引力/难以实施/令人厌恶），不是第五条原则。它有两种正当用途：

1. 戒除竞争行为：某个明确行为会吃掉启动窗口，且用户愿意处理它。不要默认给每个子日程加倒置；能把旧行为挪到新行为之后当奖励，就不要要求用户戒掉它。
2. 正向奖励实在找不到时，给目标习惯配反向激励：没做就立刻付出一个小代价。用户明确提出想用时，也可直接采用。

反向激励的使用条件：

• 只在正向方案确实凑不出来时使用，永远先试正向。同一个环节不要既给正向奖励又加惩罚。
• 代价必须小、当场生效、且必然被执行。金额小到不心疼但不想白给（十元级别），或者取消一项当天的小享受。
• 需要第三方时，指定一个具体的人和一个具体的转账动作，不写「找人监督」这类没有落点的安排。
• 判定条件用最低完成标准，不用质量。做到入口动作就算过关，不许因为「做得不好」触发惩罚。
• 习惯尚未稳定时不加金额较大的惩罚，不加连带条款，不叠加多重代价。用户表现出压力或开始回避时立即撤掉。
• 不把反向激励写成用户的道德问题，它只是一个价格。

每个建议必须符合现实环境，且能写成可观察动作。避免“保持专注、增强动力、形成意识”这类不可执行表述。

只为用户给出的子日程建环节。 用户描述的前置区间（吃饭、通勤、刷手机、已经开着的电脑）不单独成环节，只作为触发、奖励和环境约束被取用，判定标准见「区分『系统』与『前置区间』」。

写完一个环节后回查：这条链里还有没有需要临场决定的地方（做哪个、去哪儿、用什么、做多久）。有就当场定死，不留给用户现场选。

阶段 4：反馈迭代

展示 Vn 表格后，向用户索取逐环节反馈。用户可只改一行。

每轮严格执行：

1. 把用户反馈原意追加为“我的修改建议（第 N 次）”。
2. 在其后追加完整的 V(n+1) 表格；未修改项沿用上一版。
3. 不覆盖历史版本，除非用户明确要求“直接迭代到当前版本”。
4. 版本正文只放表格和必要的完成定义；分析、依据、注意事项全部放到 ---------- 分隔符之后。
5. 更新版本索引和“当前生效版本”。
6. 同步更新文末速查卡，避免速查卡与最新表格冲突。
7. 简短说明这次改了什么，不重复整份文件。

面对用户纠正时，以其真实作息、工具和偏好为准。若建议需要意志力维持，承认问题并重做。

用户报告“没做到”时，先按四个步骤定位断点再改：是没被触发、不想动、开不了头，还是做完没回报。改对应的那一条，不要笼统地把所有环节都调松。

阶段 5：确认与最终固化

当用户明确说“确认、就这样、定稿、可以执行”等：

1. 在同一文件追加“最终版 · Vn”。
2. 最终版必须整合：
   • 原有习惯系统全文（若输入不是“无”）
   • 新增/更新后的全部子日程
   • 每个子日程的时间段、触发动作、最低完成标准、奖励
   • 子日程间的无缝接力或断点存档
   • 断链补救规则：决不连错两次；错过时当天任何时间完成入口动作即算不断链
   • 一屏速查卡
3. 删除仅用于讨论、已被否定的注意事项；保留必要边界。
4. 做一致性检查：
   • 时间是否冲突
   • 触发是否真的会发生，且写成了具体动作
   • 是否仍有现场决策
   • 入口动作是否两分钟内能做完
   • 最低版本是否足够小
   • 奖励是否立即兑现，且与该习惯的目的不冲突
   • 四个步骤（提示/渴求/反应/奖赏）有没有哪一步是空的
   • 是否不必要地依赖意志力
   • 新系统是否真正接入原有系统
5. 明确告诉用户最终文件路径与当前版本。

设计判断

可靠触发器排序

优先使用：

1. 必然发生的物理事件：上车、刷卡、解锁、坐下、打水回来
2. 已稳定的旧习惯：吃完饭、洗漱完、散步回来
3. 上一环节留下的可见状态：打开的文件、未发送的输入框、桌面物件
4. 一次设好的固定闹钟
5. 临时提醒、记忆、自我鼓励

越靠后，越容易依赖意志力。

区分「系统」与「前置区间」

用户在输入 1 或输入 3 里给的内容，未必是一个系统。先判断：

• 系统：已经按四大定律设计过，有明确的触发、启动动作、最低完成标准和奖励，能不靠意志力启动。只有这种才算原有系统，才需要在文件里完整保留、标注连接点。
• 前置区间：只是日程开始前会发生的既有事实，例如「8 点吃饭，8 点半吃完，然后刷手机」「上午在公司，电脑开着」。它没有被设计过，只是背景。

判定为前置区间时：

• 不把它当作一个环节。 不给它单独的环节标题、不给它设计四大定律表格、不给它定最低完成标准和奖励、不在速查卡里给它单独一行。
• 直接取用其中的要素：把结束动作拿来当触发，把其中用户喜欢的活动拿来当前置或事后奖励，把地点、设备、干扰写进环境约束。
• 只在描述触发和接力时提到它，例如「吃完站起来 → 立刻换运动装」。
• 不要为了让文件看起来完整，把用户的日常背景补成一个个环节。用户要设计的只有他给出的那些子日程。

判断不确定时按前置区间处理。把背景误当系统，会凭空多出一堆用户没要求、也不会执行的环节。

接入原有系统

若用户提供了原有系统，优先把新习惯交由它触发：

• 复用原有的固定时间、地点、闹钟、APP、模板和奖励。
• 不破坏已稳定的链条；尽量把新动作放在原动作之后。
• 新动作过重时，先接入两分钟/一句话/空文件等最小版本。
• 清楚标注“原有部分”“新增部分”“连接点”。

不应做的事

• 不把所有四原则强塞进每个环节。
• 不把“降低难度”误判为“提高吸引力”。
• 不把远期结果、播放量或年度目标当作唯一奖励。
• 不用复杂工具替代一个已经可靠的简单动作。
• 不在用户建立习惯阶段追求优化产出。
• 不擅自改变用户已明确给定的时间、工具、奖励或完成标准。
• 不把一次失败解释为品格或意志力问题。
• 不就最低完成标准、奖励或子日程细节向用户提问；直接给建议。
• 不在版本正文里留“待确认清单”“请你选择”“需要你补充”这类占位内容。
• 不为连续时间段虚构不存在的中间行为。
• 不用错定律去修问题（用降难度修提示、用加奖励修摩擦）。
• 不用与习惯目的冲突的奖励（用暴食奖励运动、用刷视频奖励早睡）。
• 不承诺“21 天/66 天养成”，不给养成天数。
• 不把制定和修改这份文件当作进展；只有真实启动次数算数。
• 不把用户的前置区间（吃饭、通勤、刷手机）补写成环节，也不给它配四大定律和完成标准。
• 不在正向奖励可用时改用惩罚，不在同一环节同时上奖励和惩罚。