以验收标准驱动创作LifeOS ISA 的 e3-essay 示例如何用 34 条 ISC 工程化一篇 1500 字随笔【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS导读本文围绕 LifeOS 的 Ideal State ArtifactISA示例库中的e3-essay.md展开剖析一份面向「写作」这一体验型任务的完整理想状态工件——从任务前件、愿景、边界约束到 34 条可验证验收标准ISC、测试策略与功能切片。读完你不仅能看懂 ISA 如何把「写一篇好文章」这种模糊目标拆成可探针验证的工程目标还能直接复用它来管理自己的创作型、设计型工作。一、示例定位e3-essay 在 ISA 示例库中的角色在 LifeOS 的 ISA 技能体系中e3-essay.md属于示例库LifeOS/install/skills/ISA/Examples/中Art体验型分类下的 E3 档参考件。技能说明文档SKILL.md对它给出了明确定位Write a 1500-word essay on a specific thesis. Experiential goal, antecedent ISCs, post-publish reception probes.示例库按「代码 / 艺术 / 设计 / 运维 / 市场 / 企业」等域组织同属体验型的还有e5-album.md12 轨器乐专辑、e4-brand-identity.md金融科技品牌识别等canonical-isa.mdBeanLine 咖啡交易市场则是全示例库的旗舰参照件。文档头部有一行重要注释这是虚构教学示例随笔主题只是教学占位符与任何真实文章或作者无关——这意味着分析它时关注点是「这份 ISA 的形态与结构」而不是主题本身。从文档结构看这是一份写作类任务的完整 ISA包含了 frontmatter、Problem、Vision、Out of Scope、Principles、Constraints、Goal、Criteria34 条 ISC、Test Strategy、Features、Decisions 等全部核心段落。SKILL.md 同时指出示例文件属于历史产物仍带effort:、mode:等已退役的 frontmatter 键和旧式## Criteria标题——当前版本以十七节正文结构为准但示例「在形态上仍然有效」。1.1 frontmatter任务的第一份元数据文档开头的 YAML frontmatter 定义了任务的基本盘task: Write a 1500-word essay on why most productivity advice fails first-time founders slug: 20260317-203000_essay-productivity-fails-founders project: ProductivityEssay effort: advanced effort_source: explicit phase: execute progress: 12/34 mode: interactive started: 2026-03-17T03:30:00Z updated: 2026-03-21T15:00:00Ztask8 词左右的任务描述当前 Scaffold 工作流的规范要求即是 8 word task descriptionslugYYYYMMDD-HHMMSS_kebab-描述这是 ISA 文件的规范命名phase: execute与progress: 12/34生命周期阶段与已关闭 ISC 的机械计数34 条中已有 12 条勾选started/updated时间戳。按文档内 ISC-32 的约定发布时published_at与started必须反映真实 ≥4 天的酝酿期——时间戳本身就是验收对象。在现行规范Scaffold.md 的 frontmatter 说明、ISAFormat.md中effort:/mode:等键已退役2026-07-11新增任务不再写入但示例保留它们用于历史参照。二、写作的起点Problem 与 Vision 把「模糊愿望」定义成「可完成的状态」2.1 Problem先讲清楚「为什么现在的状态不可接受」写作任务最常见的失败不是「不会写」而是「没有成型目标」。e3-essay 的 Problem 段落把这一点说得很具体作者有一个关于「为什么通用生产力建议time-blocking、deep work、eat the frog对没有团队的 6 个月初创公司创始人失灵」的论点但论点只在脑子里、不在纸上一周前开始的草稿读起来像一串抱怨而不是有形状的论证——开头钩子弱、贯穿主线在第三节死掉、结尾打在空气上。没有结构框架文章会以同样的方式持续失败。这段话示范了 ISA 对 Problem 段的要求指出当下 broken 的具体表现草稿像抱怨、主线断掉、收尾无力而不是空泛地说「我想写得更好」。它同时预告了整份工件的核心解法——用一个结构框架即 ISA 本身来约束写作。2.2 Vision体验型任务的「狂喜惊喜」契约Vision 描述完成后的理想读者体验一篇 1500 字的文章首次创业者八分钟内读完、第二段就认出自己的处境、跟随一条承重论证穿过三个乐章结尾重新定义他们与生产力建议的关系——不是「忽略它」而是「暂时忽略大部分并学会分辨哪 20% 适用」。狂喜惊喜euphoric surprise读者关掉标签页、打开笔记文件、写下一句话未来 90 天他要忽略哪条生产力建议。然后他把文章告诉一位朋友。注意「第二段认出自己」「向一位朋友转发」这类描述——它们不是修辞而是为后文 ISC-13、ISC-29、ISC-30 埋下的可测量体验目标。这正是体验型 ISA 与工程型 ISA 的分水岭Vision 里写的是读者反应而非功能清单。可对照同一示例库中工程型旗舰 canonical-isa.md 的 Vision卖家周五发货、无节日无砍价无私信拉锯体验型 Vision 的「读者八分钟内读完并转发」显然需要不同的验证手段。三、三条边界Out of Scope、Principles、Constraints3.1 Out of Scope预先声明「这篇文章不是什么」文档用五个排除项锁死作品形态不是生产力建议清单不要「给创始人的 5 个生产力技巧」文章是结构性批判而非新建议不是宣言不要「这就是新方法」结论是校准calibration而非替代不点名任何创始人不依赖读者认识某个具体创始人的故事论证必须对从没读过 TechCrunch 的读者成立不是 Twitter 线程长文、单一文档、一次性连续读完不是研究论文零引用、零脚注论证的力量来自清晰而非外部权威。从方法论上看这五点把「容易顺手写进去的东西」提前隔离。SKILL.md 的三护栏分类表SKILL.md明确指出Out of Scope 约束的是Vision属声明式散文而它后续会通过派生为反标准Anti-criteria变成可探针验证的约束——e3-essay 的 ISC-18、ISC-20、ISC-21 正是从这几条 Out of Scope 派生出来的。3.2 Principles约束「思考方式」的五条写作信条读者在第二段的「认出感」是承重时刻——它不落地后面什么都不落地一条论点、一条主线——任何需要读者并行持有第二论证的内容都删掉具体 抽象——每个论断背后都有具体情境否则读起来像陈词滥调结尾必须做事——点名一件读者会做得不一样的事而不是只做总结语气是对话式直白——不要「Heres the thing」、不要「It turns out」、不要学术式含糊。Principles 约束的是思考本身aspirational、可泛化与约束解决方案空间的 Constraints 相区分。值得注意的是Principles 第 5 条直接指向了后文 ISC-9 与仓库中的 AI 写作模式黑名单。3.3 Constraints不可动摇的写作硬约束1500 词 ± 100最终 1400–1600 词只允许三个章节——开头、中段、收尾禁止小标题阅读时间 ≤ 8 分钟按 200 wpm零脚注、零引用、零「正如名人所说」正文中禁止项目符号列表结尾允许一个若它配得上以带 frontmatter 的单个 Markdown 文件发布无内嵌图片、无 pull quote。这些约束与「三章节无小标题」直接服务于主线承重形式约束迫使主线必须承重——这一因果关系在 Decisions 的第一条记录中被明确写下来。四、Goal一句可验证的「完成」Goal 段落把整个任务压缩为一段可验证陈述交付一篇 1400–1600 词、分三节的随笔开头是一个首次创业者在 30 秒内认出的具体情境发展出一条单一论点「大多数生产力建议是为另一种游戏设计的」结尾给出读者 24 小时内就能应用的校准工具——一个用于判断「哪条建议该留、哪条该丢」的单问题过滤器。对比canonical-isa.md的 Goal含「p95 ≤ 1s」这类数字预算这里 Goal 的可验证性不在数字而在于它点名了三个可被 ISC 逐条覆盖的交付物30 秒认出情境→ISC-13、单线论点→ISC-5/ISC-8、24 小时可用的校准工具→ISC-7/ISC-15。Goal 与 ISC 之间的这种「承重对应」正是 ISA 设计的核心。五、34 条验收标准ISC全解析写作质量如何变成可勾选项e3-essay 把「好文章」拆成了 34 条 ISC按领域分十组。每条都遵循同一形态- [x] ISC-N: 可验证的表述probe: 验证方式。这也是 ISAFormat.md 规定的现行格式ISC-N全局顺序编号、Anti:/Antecedent:为仅有的两个语义前缀。5.1 字数与结构ISC-1 ~ ISC-4ISC内容探针ISC-1正文字数 ∈ [1400, 1600]wc -w essay.md扣除 frontmatterISC-2恰好三个顶级章节、无小标题rg -c ^## essay.md返回 3ISC-3每节 350–700 词各节标题之间的词数统计ISC-4阅读时间 ≤ 8 分钟200wpmwc -w / 200ISC-1/ISC-2 已勾选[x]ISC-3/ISC-4 未完成——progress: 12/34正是这样机械统计出来的。5.2 论证结构ISC-5 ~ ISC-8ISC-5开头节以一句话论点收尾人工复核确认——已勾选ISC-6中段通过 ≥3 个独立具体例证推进论点不依赖外部知识——未勾选ISC-7结尾点名一个具体校准工具单问题过滤器读者 24 小时内可应用——未勾选ISC-8贯穿线测试——3 位陌生读者单次阅读后各用 ≤20 词复述论点≥2/3 落在同一摘要 ±10 词内——未勾选。这组标准把「论证有力」从主观印象变成了可执行的读者测试协议。5.3 语气与用词ISC-9 ~ ISC-12ISC-9全文零出现「Heres the thing」「It turns out」「Not just X — its Y」探针对照 AI_WRITING_PATTERNS 黑名单跑 rg 返回 0——已勾选ISC-10零脚注、零数字引用、零「正如某人所说」探针rg \[?\^?\d\]与rg as [A-Z]均返回 0ISC-11句长方差——每节至少一句 ≤8 词、至少一句 ≥28 词按节做句长直方图ISC-12全文第一人称复数we/us/our≤ 5 次rg -wc we|us|our。ISC-9 直接引用了仓库中的 AI_WRITING_PATTERNS.md。该文件是 LifeOS 的「AI 写作痕迹黑名单」P0 级「Let me know if...」「In conclusion...」等、P1 级「Heres the thing...」「Not just X — Y」等、P2 级个人风格偏好。e3-essay.md是把它作为可执行验证源的直接证据。5.4 Antecedent 前件标准体验型任务的核心契约ISC-13 ~ ISC-15这三条是本文档最重要的方法论特征ISC-13前件——第二段包含一个具体情境60% 首次创业者 30 秒内认出是自己的处境探针5 位陌生创始人读者≥3/5 在阅读后单问调查中勾选「对这就是我」ISC-14前件——论点句难以改动hard-to-vary——用同义词替换其中任何名词或动词都会明显削弱论证3 个改写版本人工复核均有明显语义损失ISC-15前件——结尾校准工具足够具体读者不重读全文即可应用5 位只拿到结尾节的读者≥4/5 能说清要做什么。SKILL.md 对 Antecedent 有明确规则当目标是体验型艺术、设计、内容、任何需要「落地」的东西时至少一条 ISC 必须带Antecedent:前缀命名一个「可靠产生目标体验的前件」可验证型目标构建、部署、Schema不需要前件。这组前件把「读者被感动」这个无法直接验收的目标转译为「第二段被 60% 目标读者认出」这种可调查的前件——文档底部注释解释得很清楚没有这三条前件ISC-29/ISC-30发布后接受度就只是不可证伪的希望而不是可测试的声明。5.5 Bitter Pill 纪律ISC-16 ~ ISC-17ISC-16任何段落挪到别的文章里都必须至少重写首句段落可移植性审查——每段至少有一个短语把段落锚定到本文的特定论证ISC-17没有任何句子是填充物——删除任何一句都会明显削弱论证或节奏朗读测试随机抽 3 句做删除实验。这是 LifeOS 的 Bitter Pill苦药原则在写作域的落地拒绝一切「看起来无害但可删除」的内容。BitterPillEngineering 是仓库 skills 库中的独立技能此处以 ISC 形式内嵌进写作任务。5.6 反标准 Anti-criteriaISC-18 ~ ISC-21ISC-18Anti: 范围——文章不得包含编号的生产力技巧清单探针rg ^\d\.返回 0ISC-19Anti: 回归——任何句子不超过 50 词最长句 ≤50 词一条 50 词长句就是文章滑向学术腔的「金丝雀」ISC-20Anti: 语气——文章不得点名具体知名创始人探针rg -i paul graham|sam altman|peter thiel|naval|elon|jeff bezos|steve jobs返回 0ISC-21Anti: 范围——文章不得提出新的生产力框架或系统人工确认零「Introducing the X method」表述。按 SKILL.md 的三护栏分类表Anti-criteria 是 Out of Scope / Constraints / Principles 三条声明式护栏的可测试派生形态——它们把「不要清单」「不要宣言」「不要点名」变成rg一行命令。CheckCompleteness 工作流CheckCompleteness.md要求 substantial 级以上任务至少一条反标准缺失即硬失败。5.7 迭代纪律ISC-22 ~ ISC-24ISC-22定稿前drafts/目录至少留存 3 个草稿ls drafts/ | wc -l≥ 3ISC-23定稿前至少朗读全文一遍Decisions 条目确认朗读遍ISC-24至少 2 位陌生读者非客套朋友在发布前给出第一印象反馈Decisions 条目记录读者 ID/缩写。5.8 发布ISC-25 ~ ISC-28ISC-25最终文件为项目根目录essay.mdfrontmatter 含title、published_at、word_count、reading_time_minISC-26目标平台预览渲染干净三个章节、无格式破损ISC-27为社交分发捕获一条 ≤280 字符的 pull-quote文件pullquote.txt存在且 ≤280 字符ISC-28为未来重读捕获一条「如果必须再砍 200 词」的笔记cuts-on-deck.md列出候选删减。5.9 发布后的狂喜惊喜探针ISC-29 ~ ISC-30ISC-297 天内 ≥1 位读者反馈自己识别出要丢弃的一条建议搜索回复/评论/私信ISC-3014 天内 ≥1 位读者主动把文章转发给同为创始人的朋友web 分析来源或直接报告。这两条把 Vision 里的「告诉一位朋友」落实为发布后可观测的量化探针——体验型任务不因「发布」而结束验收延伸到真实读者反应。5.10 个人纪律ISC-31 ~ ISC-34ISC-31cuts.md保留「我删了什么」文件展示被编辑掉的内容文件存在且 ≥500 词删减量ISC-32frontmatter 的started与published_at时间戳反映真实 ≥4 天酝酿期ISC-33一条简短 Decisions 记录「哪个段落重写最多次、为什么」供下一篇文章借鉴ISC-34至少一条 ❌ DEAD END 的 Decisions 条目尝试过并放弃的草稿方向。六、Test Strategy把主观质量翻译成可运行探针Test Strategy 段落用 YAML 表列出每条关键 ISC 的验证方式格式为isc | type | check | threshold | tool- isc: ISC-1 type: word-count check: total words in body threshold: 1400-1600 tool: awk /^---$/{c; next} c2 essay.md | wc -w - isc: ISC-8 type: reader-comprehension check: 3 unfamiliar readers articulate thesis in ≤ 20 words within ±10 of each other threshold: ≥ 2/3 cluster tool: send essay to 3 reader-test slots, collect 1-sentence summaries - isc: ISC-9 type: ai-writing-pattern check: AI-writing-pattern density threshold: 0 occurrences from P0 list tool: rg -i heres the thing|it turns out|not just .* — its essay.md - isc: ISC-13 type: antecedent-probe check: 5 founder readers say yes, thats me to second paragraph threshold: ≥ 3/5 tool: 5-person reader test, post-read 1-q survey - isc: ISC-29 type: post-publish check: ≥ 1 reader names a specific advice theyre dropping threshold: 1 within 7 days tool: monitor replies, comments, DMs for 7 days值得注意的三点工程细节探针分可运行与人工两类wc -w、rg、awk这类命令探针可随时重跑读者调查、发布后监控则依赖外部参与者——后者正是体验型任务无法绕开的验证成本。字数探针要扣除 frontmatterawk /^---$/{c; next} c2提取第二个---之后即正文再数词避免 YAML 元数据污染字数验收。现行规范要求六列SKILL.md 的 Gotchas 明确指出Test Strategy 表必须携带isc | type | check | threshold | tool | anchors_to六列因为 Bunker 解析器按位置读取anchors_to若删掉threshold列锚点会错位到tool槽导致ISAGate.ts硬失败anchors-missing。e3-essay 作为历史示例未带anchors_to符合其创作时期的格式但新建 ISA 应遵循六列规范。七、Features把 34 条标准组织成 5 个纵向功能切片Features 段落把 ISC 重新组织为 5 个功能块每个块带satisfies满足哪些 ISC、depends_on依赖哪些块和parallelizable可否并行Feature描述satisfies依赖可并行OpenerSituation读者 30 秒内认出的具体首次创业情境ISC-3, 5, 13, 16无否——开头门控一切MiddleArgument三个具体例证推进单一论点ISC-3, 6, 11, 14, 16OpenerSituation否——主线是顺序的CalibrationClose24 小时内可应用的单问题过滤器ISC-3, 7, 15, 30MiddleArgument否VoicePassAI 写作模式清除 句长方差 第一人称纪律ISC-9, 10, 11, 12, 19, 20CalibrationClose是——全文上的润色遍ReaderFeedback两轮陌生读者反馈第二段认出探针ISC-8, 13, 15, 23, 24VoicePass是——读者相互独立从依赖链可见一个清晰的顺序流水线开头情境 → 中段论证 → 校准结尾 → 语气润色 → 读者反馈。前三块串行写作的承重结构不可并行后两块可并行读者与润色互不阻塞。这符合 SKILL.md 的「Features 是纵向切片」原则——每个 Feature 都端到端切向一个可独立验证的增量而不是「数据层/API 层」式的水平分层。八、DecisionsDEAD END 与 refined 的记录价值Decisions 段落按时间戳记录了 6 条决策其中 2 条 ❌ DEAD END、3 条refined:重构、1 条锁定决策2026-03-17 03:30锁定三章节、无小标题——形式约束迫使主线承重2026-03-18 11:00❌DEAD END曾尝试用公众人物引言开头感觉是借来的读者认出感停留在外部回退为具体情境开头不要重试2026-03-19 22:30refinedISC-13 从「读者觉得开头 relatable」锐化为「≥3/5 创始人读者专门对第二段勾选『对这就是我』」——前者不可证伪后者隔离了承重时刻2026-03-20 09:00❌DEAD END中段尝试五个例证而非三个第四、五个开始互相重复砍到三个并扩展其中一个不要重试2026-03-20 14:30refinedISC-7 从「结尾给出 takeaway」锐化为「结尾点名一个 24 小时内可应用的具体校准工具」——含糊结尾正是大多数此类随笔失败的原因2026-03-21 09:00refinedISC-12 新增第一人称复数 ≤5因某稿读起来像「我们都应该」式说教——文章是观察不是规劝。这套记录的工程价值在于dead end 和 refined 不是失败痕迹而是防止重蹈覆辙的审计线索。SKILL.md 的 Gotchas 进一步规范了这种记录——## Decisions是常驻的「活表面」改动目标refined:前缀与废弃方向❌ DEAD END都必须留痕ISC 编号永不重排被删 ISC 也要留墓碑- [ ] ISC-N: [DROPPED — see Decisions ...]以保障 Reconcile 工作流按稳定 ID 合并时不静默断裂。九、仓库中的方法论支撑这份示例背后的完整系统e3-essay.md不是孤立文件它由一整套规则与工作流支撑技能规范SKILL.md定义十七节正文结构、按实质分级的 Completeness Gatetrivial Goal Claimssubstantial 全套结构deepest 全部节 构建前跑 Interview 工作流、七个工作流的动词路由表以及十余条 GotchasID 稳定性、ephemeral 文件是派生视图、changelog 即 git、C/R/L 四件套学习格式、Verification 一行存根、空节不出现、体验型目标必须有 Antecedent、反标准至少一条、Fog 不是声明等。e3-essay 中的 Antecedent、Anti-criteria、Features 块、Test Strategy 表、Decisions 记录全部是这些规则的实例化。工作流Workflows/Scaffold.md从提示词生成 ISA——先原样保留 principal 陈述的目标再派生其余内容Splitting Test 保证每条 ISC 只含一个二元探针体验型目标要求至少一条 Antecedent最后必须跑 CheckCompleteness 才能返回CheckCompleteness.md对 ISA 评分并输出结构化 pass/fail 报告严重度表明确列出「体验型缺 Antecedent hard」「substantial 级缺反标准 hard」等硬失败项Interview.md当提示词信号不足时逐节追问Vision 问「完成时用户感觉如何」「狂喜惊喜长什么样」等答案即写回文档——e3-essay 的 Vision 段落正是这类提问的典型产物。格式规范ISAFormat.md规定 ISC 行格式- [ ] ISC-N: criterion text、Anti:/Antecedent:为唯一语义前缀、教义底线反标准 ≥1体验型 Antecedent ≥1。SKILL.md 声明「格式规范优先」——若技能散文与格式规范冲突以规范为准。写作黑名单AI_WRITING_PATTERNS.mdISC-9 的探针数据源P0/P1/P2 三级「AI 写作痕迹」清单是全文零 AI 味约束的判据。十、把 e3-essay 的模式复用到你自己的创作任务从这份示例可以提炼出适用于任何「体验型 / 创作型」任务的五步法先定义可测量的读者反应Vision不要写「写一篇好文章」要写「读者第二段认出自己、读完后写下要做的一件事、并转发给一位朋友」——反应要具体到可以设计探针。用三条护栏锁定形态Out of Scope / Principles / Constraints提前声明「不是什么」清单、宣言、点名、「思考必须尊重什么」一条主线、具体抽象、「哪些数字不可动摇」字数、章节数、阅读时长。把质量拆成 34 条可勾选标准Criteria每条标准要么能跑命令探针wc -w、rg要么能设计读者调查第二段认出率、复述一致性体验型任务必须有 Antecedent 前件 反标准。用 Features 排序执行识别承重链开头 → 论证 → 结尾中的串行部分和可并行的润色/反馈部分避免在结构未定前做美容性工作。让 Decisions 成为审计资产每条 DEAD END 标注「不要重试」每条 refined 记录锐化方向——下一篇文章从上一篇的教训开始而不是从零开始。对于 LifeOS 的完整使用方式ISA 技能通过Skill(ISA, scaffold from prompt: ...)被 Algorithm 在运行开始时调用或由用户直接调用新建 ISA 默认落在MEMORY/WORK/{slug}/ISA.md任务级或project/ISA.md项目级强制 substantial 结构闭环由 CheckCompleteness.md 在phase: complete前把关任何硬缺口都会阻止完成态转换。e3-essay.md就是这条流水线在「写一篇文章」上的完整标本——它证明了一件事当「完成」被写成 34 条可探针的声明写作就不再依赖灵感赌博而是变成一条可验证、可复盘、可迁移的生产路径。【免费下载链接】LifeOS⛰️ The Life Operating System — an intent engineering platform that moves you from your current state to your ideal state, in life and work.项目地址: https://gitcode.com/GitHub_Trending/pe/LifeOS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
