企业官网建设流程全解析

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模式展开：它如何用code_helper扫描现有项目并生成结构化 JSON，再经 AI 生成受约束的文件变更清单，最终把改动直接应用到你的代码库。读完本文，你将掌握该模式的完整安装、调用命令、输入输出协议（JSON 结构与__CREATE_CODING_FEATURE_FILE_CHANGES__输出标记）、安全边界设计，以及结合 git 审查回滚的完整实战工作流。

模式定位：在 Fabric 模式体系中的位置

create_coding_feature是 Fabric 提示模式（prompt pattern）体系中的一个“创建类”模式，专注于对已有编码项目生成代码变更。仓库内 模式说明文档 对其定义是：

基于项目规格，使用现代技术与最佳实践生成安全、可组合的代码功能。

在 Fabric 的模式目录中，它与create_coding_project（从零生成项目骨架）形成互补：前者输入是“一个真实存在的项目 + 一条变更指令”，输出是“可落地的文件变更”；后者输入是“一句想法”，输出是“项目结构 + 起步代码”。该模式位于 Patterns/create_coding_feature/ 目录，目录内包含 README.md（使用说明）与 system.md（提示词本体）两个文件。

整个 Fabric 技能由 SKILL.md 定义，内置 240+ 个模式，按 Extraction、Summarization、Analysis、Creation、Improvement、Security、Rating 分类组织。create_coding_feature属于 Creation（创建）类别下的开发向模式，在 suggest_pattern 模式 中被归入 DEVELOPMENT 分类，与create_coding_project、review_code、explain_code等模式并列。

安装与基本用法

根据 README.md 的 Installation 一节，该模式依赖code_helper二进制（fabric 项目自带的 Go 工具），安装方式：

go install github.com/danielmiessler/fabric/cmd/code_helper@latest

基本用法是一行管道命令：

code_helper [project_directory] "[instructions for code changes]" | fabric --pattern create_coding_feature

其中：

• code_helper接收两个参数：项目目录路径（如.表示当前目录）和一段自然语言的变更指令；
• 它的标准输出（项目 JSON 表示）通过管道交给fabric；
• --pattern create_coding_feature指定执行的模式，fabric 会加载该模式的system.md提示词，结合 JSON 输入让模型生成文件变更。

官方给出的最小示例：

code_helper . "Create a simple Hello World C program in file main.c" | fabric --pattern create_coding_feature

输入协议：code_helper 生成的项目 JSON

模式提示词 system.md 明确定义了模型收到的输入是一个 JSON 数组，包含三种对象：

1. 项目快照（type: "directory"）：递归描述目录与文件，文件对象携带name和完整content字段；
2. 统计报告（type: "report"）：目录数与文件数；
3. 变更指令（type: "instructions"）：name固定为code_change_instructions，details字段承载你传入的自然语言指令。

文档给出的输入示例：

[ { "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" } ]

这套协议的关键价值在于：模型在生成变更之前，看到了项目的真实文件内容，而不是凭猜测写代码——这是该模式能做到“精准修改现有文件”而非泛泛输出代码片段的前提。

输出协议：__CREATE_CODING_FEATURE_FILE_CHANGES__变更清单

system.md 定义了模型必须使用的“文件管理接口”输出格式。模型需要以__CREATE_CODING_FEATURE_FILE_CHANGES__标记开头，随后输出一个 JSON 数组，每个元素包含operation、path、content三个字段：

__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;}" } ]

接口语义有明确的边界（见 system.md 的 Important Guidelines 与 Constraints 一节）：

• 列表中不存在的文件会被创建，不存在的目录会被自动创建，已存在的文件会被覆盖；
• 不允许删除文件（“It is not possible to delete files”）；
• 所有路径必须相对项目根目录，绝不允许创建项目根目录之外的文件；
• 生成的代码要求完整、可运行、生产可用，且“不信任外部输入，假设用户是恶意的”；
• 代码需为每一步添加注释，不使用已废弃的特性。

输出章节（Output Sections）还规定了若干工程约定：必须输出变更摘要，__CREATE_CODING_FEATURE_FILE_CHANGES__章节绝不可省略且格式不得偏离；若变更影响项目的构建与安装方式，要同步更新 README.md；如需构建配置变更，在项目没有现成构建系统时优先选择 ninja；新依赖要按项目所用语言的最佳实践记录（如 requirements.txt、go.mod 等）。

完整实战工作流

README.md 的 Example Workflow 一节给出了一条“生成—审查—验证—提交”的完整链路：

# 1. 请求 AI 创建一个 Hello World 程序 code_helper . "Create a simple Hello World C program in file main.c" | fabric --pattern create_coding_feature # 2. 审查对项目做的变更 git diff # 3. 运行/测试代码 make check # 4. 确认无误后提交 git add <changed files> git commit -s -m "Add Hello World program"

其中 fabric 在执行到第 2 步之前会解析 AI 生成的变更清单并提示用户确认，确认后才会真正写入文件。README 同时给出一个典型的“安全加固”用法，说明该模式适合批量、指令式的安全修复：

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 validation"

值得强调的两条注意事项（README 的 Important Notes）：

• 始终从项目根目录运行：文件变更是相对当前目录应用的，目录不对会导致落点错位；
• 必须配合版本控制使用：README 明确指出“你不会被要求逐条批准每次变更”（You willnotbe asked to approve each change），因此强烈建议在干净的 git 仓库中使用，以便用git diff审查、用git checkout回滚。

安全设计：五层防护

综合 README.md 的 Security Features 一节 与 system.md 的提示词约束，该模式的安全边界可以归纳为五个层面：

从 system.md 的约束措辞看，提示词层（模型自律）与应用层（fabric 解析器强制校验）是双重防线：即使模型输出了越界路径，fabric 侧的路径校验与操作校验仍会拦截。结合 git 的审查与回滚能力，构成了“生成前看全貌、生成中受约束、生成后可追溯”的完整闭环。

在 LifeOS 中的执行方式

需要说明的是，本仓库中 Fabric 技能的集成方式与原始 fabric CLI 略有不同。根据 SKILL.md 与 ExecutePattern 工作流：LifeOS 对大多数模式采用原生执行——由 Agent 直接读取Patterns/{pattern_name}/system.md并作为提示词应用，不再调用 fabric CLI 往返（CLI 仅保留-yYouTube 转写与-uURL 抓取两个用途）。

这带来一个实践上的差异：create_coding_feature的核心输入（项目 JSON 快照）仍然依赖code_helper生成，但模式的 system.md 可以由 LifeOS 的 Agent 直接加载执行。也就是说，即使不安装 fabric CLI，也可以让具备 Fabric 技能的 Agent 读取 system.md 并按其协议处理code_helper的输出。另外，Fabric 技能在执行工作流后会向执行日志追加一条 JSONL 记录（见 SKILL.md 的 Execution Log 一节），便于事后审计模式使用情况。

与create_coding_project的分工

Fabric 模式库中的另一个开发向模式 create_coding_project 面向“从想法到项目骨架”：输入一句echo "INSERT_YOUR_IDEA_HERE"，输出 PROJECT / SUMMARY / STEPS / STRUCTURE / CODE / SETUP / TAKEAWAYS 等章节的起步代码与搭建脚本。两者可以串成完整链路：先用create_coding_project立项，再用create_coding_feature在项目中迭代添加功能。

已知限制与后续改进方向

README 末尾的 Suggestions for Future Improvements 一节列出了当前模式的改进路线，也侧面反映了当前的能力边界：

• 增加 dry-run 模式，只展示变更而不实际应用；
• 增强变更报告，输出详细的变更摘要；
• 支持带安全检查的文件删除；
• 增加项目级规则的配置选项与项目特定的校验规则；
• 提供已应用变更的回滚能力；
• 增强脚本生成的条件逻辑；
• 记录更详细的 API 响应日志；
• 考虑提供 GUI 降低使用门槛。

其中“文件删除不可用”“无 dry-run”“无回滚”三点是使用该模式时需要用 git 习惯来弥补的现实限制。

小结

create_coding_feature是 Fabric 体系中“AI 改代码”这一场景的代表性模式：用code_helper解决“模型看不到项目全貌”的问题，用固定的 JSON 变更清单协议解决“输出不可机读”的问题，用路径/大小/操作白名单与应用前确认解决“AI 直接写盘”的信任问题。其设计范式——结构化输入 + 受约束的结构化输出 + 版本控制兜底——对任何希望把 LLM 安全接入真实代码库的团队都有参考价值。相关实现可继续在仓库中查阅：模式说明、模式提示词、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