LifeOS Fabriccreate_coding_feature模式详解AI 代码变更的机器可读文件操作契约【免费下载链接】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 仓库中 Fabric 技能的create_coding_feature模式文件 system.md 为主体完整拆解该模式定义的双向契约以 JSON 快照描述项目现状的输入格式以及以__CREATE_CODING_FEATURE_FILE_CHANGES__标记包裹的文件变更 JSON API。读完本篇后你将掌握如何复用这套模式结构让 AI 对既有代码项目产出可被程序解析、确认、落盘的安全代码变更并理解其输入 schema、输出纪律与安全约束的设计意图。模式定位LifeOS Fabric 中的 240 提示模式之一create_coding_feature是 LifeOS 内置 Fabric 技能见 Fabric/SKILL.md所管理的 240 个专业提示模式prompt patterns之一存放在 Patterns/create_coding_feature/ 目录下包含两个文件system.md——模式的完整系统提示词即本篇的核心分析对象README.md——配套的使用说明描述如何通过code_helper与fabric命令行管线执行该模式。从 Fabric 技能的执行模型看模式采用原生执行ExecutePattern 工作流会读取Patterns/{pattern_name}/system.md把其中的 IDENTITY、STEPS、OUTPUT 指令直接作为提示词套用不需要每次调用外部 CLIfabric命令仅保留给 YouTube 字幕提取-y和 URL 抓取失败回退-u两个场景。在官方模式目录清单 pattern_explanations.md 中该模式的定位被概括为create_coding_feature: Generates secure and composable code features using modern technology and best practices from project specifications.即针对既有项目从项目规格与变更指令出发生成安全、可组合的代码特性变更。角色定义与处理流程system.md 的第一部分# IDENTITY and PURPOSE给出了模式的角色设定You are an elite programmer. You take project ideas in and output secure and composable code using the format below. You always use the latest technology and best practices. Take a deep breath and think step by step about how to best accomplish this goal using the following steps.角色设定强调三个关键词安全secure、可组合composable、现代技术栈与最佳实践。随后要求模型深呼吸、分步思考这是对链式推理step-by-step reasoning的显式引导。模式随后给出一个四步标准工作流Workflow 一节分析用户的请求确定所需的文件操作create 还是 update给出清晰、可执行的建文件/改文件指令即 JSON 文件操作解释所提议变更的目的与功能。这四步与输出契约下文详述的先摘要、后 JSON结构是一一对应的模型必须既能机器化地产出操作数组又能用自然语言交代每处变更的意图。输入契约JSON 化的项目快照该模式最重要的设计决策是把输入也定义为严格的 JSON 格式而不是自由文本。system.md 中给出的输入示例如下原文完整保留[ { type: directory, name: ., contents: [ { type: file, name: README.md, content: This is the README.md file content }, { type: file, name: system.md, content: This is the system.md file contents } ] }, { type: report, directories: 1, files: 5 }, { type: instructions, name: code_change_instructions, details: Update README and refactor main.py } ]这个数组由三类对象组成各自承担不同职责对象类型字段语义type: directoryname、contents递归描述项目目录树每个子项是type: file的对象含name相对路径与content文件全文type: reportdirectories、files目录与文件的数量统计作为项目规模摘要type: instructionsname、details变更指令。name字段固定为code_change_instructionsdetails才是真正描述要做什么的自然语言指令system.md 对此有两条明确的解析规则对象中type: instructions且字段name恒等于code_change_instructionsdetails字段携带被建议的代码变更指令instructions for the suggested code changes。这种设计的实际意义在于调用方如 README 中描述的code_helper工具可以先扫描项目目录、把目录树与文件内容序列化成 JSON再拼上用户指令整个提示输入因此变成结构化的、可程序化生成的上下文。对下游解析同样有利——既然输入是 JSON 快照模型就能精确引用现有文件 X 的 Y 位置而不是凭印象改写。输出契约__CREATE_CODING_FEATURE_FILE_CHANGES__文件操作 APIsystem.md 的核心章节是## File Management Interface Instructions它定义了一套文件管理接口模型必须使用**精确EXACT**的 JSON 格式表达文件变更文件不存在时创建目录不存在时创建文件已存在时覆盖无法删除文件It is not possible to delete files。变更必须以如下标记块的形式输出原文完整保留__CREATE_CODING_FEATURE_FILE_CHANGES__ [ { operation: create, path: README.md, content: This is the new README.md file content }, { operation: update, path: src/main.c, content: int main(){return 0;} } ]每条操作的语义如下字段取值说明operationcreate/update只允许这两种操作README 中说明有 Operation validation仅放行 create/updatepath相对路径相对于项目根目录content字符串完整的文件内容标记行__CREATE_CODING_FEATURE_FILE_CHANGES__的作用是与自然语言文本做显式分隔执行端Fabric 运行时只需定位标记、截取其后 JSON 数组即可解析而不必从混杂的散文输出里猜哪段是操作。system.md 的 Output Sections 一节对这一点下了硬性要求——neveromit the__CREATE_CODING_FEATURE_FILE_CHANGES__section且不得偏离所定义的 JSON 格式。关键准则Important Guidelinessystem.md 列出了四条操作准则始终使用相对项目根目录的相对路径创建或修改文件时必须提供完整的、可运行的代码而非片段或 diff文件操作表述要精确、简洁绝不允许在项目根目录之外创建文件。安全约束Constraints这是该模式与一般提示词拉开差距的部分四条约束中两条直接面向安全不得尝试读取或修改项目根目录之外的文件代码须遵循最佳实践、达到生产可用production-ready水准代码建议中要优雅地处理潜在错误不要信任应用的外部输入假定用户是恶意的Do not trust external input to applications, assume users are malicious——这一条把安全编码从口号变成了对生成代码的具体验收标准生成结果必须自带输入校验与防御。配合 README.md 中的 Security Features 一节这套防御是双层的提示层约束模型只在根目录内生成操作、执行层再兜底做路径校验防目录穿越、文件大小限制防超大文件生成、操作类型白名单并且应用变更前需要用户确认。输出章节与格式纪律system.md 的## Output Sections定义了每次响应的固定结构先输出文件变更摘要summary of the file changes再按文件管理接口规范输出由__CREATE_CODING_FEATURE_FILE_CHANGES__标记的 JSON 数组变更若影响项目的构建与安装方式必须在项目README.md中记录这些变化需要时实现构建配置变更项目尚无构建系统时优先选择 ninja按所使用语言的最佳实践记录新增依赖不输出任何未被显式要求的章节。## Output Instructions进一步细化格式纪律不得输出警告或附注只输出要求的章节输出章节间不得重复条目保持对建议开放按上述 JSON API 输出文件系统变更输出代码中每一步都要有注释Output code that has comments for every step不使用已弃用的特性deprecated features。文件末尾的## INPUT是空的占位锚点——这与 Fabric 的通用模式模板 official_pattern_template/system.md 的骨架IDENTITY / GOALS / STEPS / OUTPUT / OUTPUT INSTRUCTIONS / INPUT思路一致模式本身是模板执行时把具体输入项目 JSON 快照 指令追加到## INPUT之后AI 即按前文契约产出。执行链路code_helper 管线与原生执行README.md 描述了该模式在 fabric 上游工具链中的完整执行链路。安装code_helper二进制go install github.com/danielmiessler/fabric/cmd/code_helperlatest基本用法是把项目目录与变更指令喂给code_helper再管道进 fabric 运行时code_helper [project_directory] [instructions for code changes] | fabric --pattern create_coding_featureREADME 给出的端到端示例工作流# Request AI to create a Hello World program code_helper . Create a simple Hello World C program in file main.c | fabric --pattern create_coding_feature # Review the changes made to your project git diff # Run/test the code make check # If satisfied, commit the changes git add changed files git commit -s -m Add Hello World program以及一个安全加固场景code_helper . Ensure that all user input is validated and sanitized before being used in the program. | fabric --pattern create_coding_feature git diff make check git add changed files git commit -s -m Security fixes: Input validationREADME 的 How It Works 一节把整条链路归纳为五步code_helper扫描项目目录生成 JSON 表示即 system.md 定义的directory快照结构AI 模型分析项目结构与指令AI 按标准格式生成文件变更即__CREATE_CODING_FEATURE_FILE_CHANGES__JSON 数组Fabric 解析这些变更并提示用户确认确认后变更被应用到项目文件。这里可以印证输入契约与输出契约的分工code_helper 负责把项目现状编码成 system.md 规定的 JSON 输入fabric 运行时负责把模型输出的标记 JSON 解析并落盘而 system.md 正是两端之间唯一的协议文件。README 的 Important Notes 给出了两条必须遵守的运行前提必须在项目根目录下运行文件变更是相对于当前目录应用的强烈建议在干净的 git 仓库中使用以便审查与回退且不会逐条询问批准每个变更——安全兜底依赖版本控制而非逐条交互确认。在 LifeOS 内部Fabric 技能的原生执行路径与此互补Agent 直接读取 Patterns/create_coding_feature/system.md用可用的文件工具自行组装项目快照并执行该契约产出同样的__CREATE_CODING_FEATURE_FILE_CHANGES__结构再由执行端解析应用。与create_coding_project的对比变更既有项目 vs 生成新项目仓库中并存的姊妹模式 create_coding_project/system.md 采用相同的角色设定You are an elite programmer...但面向完全不同的场景它接收一个项目想法输出PROJECT/SUMMARY/STEPS/STRUCTURE/CODE/SETUP等叙事型输出章节交付从零开始的完整项目骨架而create_coding_feature的输入是既有项目的 JSON 快照输出是机器可执行的 create/update 操作数组目标是增量修改而非整体生成。从源码结构看两者的分工对应了两种人机协作模式新项目用叙事型章节 人工审阅代码块既有项目用标记分隔的 JSON 操作 API 程序化应用 git 审查。对提示词工程读者而言create_coding_feature示范了如何把一个开放式任务改代码收敛为类型化输出固定标记 固定字段 白名单操作这是让 LLM 输出可被脚本可靠消费的关键手法。局限与演进方向README 的 Suggestions for Future Improvements 一节如实列出了当前实现的边界原文列举dry-run 模式、更详细的变更报告、带安全检查的文件删除支持、项目级规则配置、变更回滚、项目级校验规则、带条件逻辑的脚本生成、API 响应日志、GUI。其中不支持删除文件It is not possible to delete files在 system.md 与 README 的Operation validation (only create/update operations allowed)两处互相印证属于当前契约的既定限制而非笔误。要点速查要点内容依据模式位置Patterns/create_coding_feature/system.mdFabric 技能 240 模式之一SKILL.md、pattern_explanations.md输入格式directory快照 report统计 instructionsname恒为code_change_instructionssystem.md输出标记__CREATE_CODING_FEATURE_FILE_CHANGES__后接 JSON 操作数组禁止省略system.md Output Sections允许的操作仅create/update不可删除路径必须相对项目根禁止越界system.md Constraints、README Security Features构建约定变更构建/安装方式须写入 README无构建系统时优先 ninjasystem.md Output Sections代码质量完整可运行代码、每步有注释、禁用弃用特性、默认假定输入恶意system.md Constraints / Output Instructions执行前提项目根目录运行干净的 git 仓库中操作变更后以git diff审查README Important Notes这套模式的价值不在于任何单一提示技巧而在于把 AI 改代码这件事协议化输入是机器生成的 JSON 快照输出是机器可解析的 JSON 操作人只保留git diff审查这一个确认点——这正是 LifeOS 把create_coding_feature作为独立 Fabric 模式沉淀下来的原因。【免费下载链接】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），仅供参考