企业官网建设流程全解析

LifeOS 咨询业务目录搭建指南：用 SAMPLE_CONSULTING 模板落地你的咨询实践

【免费下载链接】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 工作区（USER/WORK）中 SAMPLE_CONSULTING 模板 的用途与搭建方法。该目录用于承载你的咨询业务上下文——服务产品（Offerings）、可复用模板（Templates）、进行中的提案与工作说明书（Proposals/SOW），是让你的数字助手（DA）用真实客户名、真实报价回答"我的管道里有什么""哪些提案还开着"这类问题的数据基础。读完本文，你将掌握如何将示例目录改造为自己的咨询实践目录，并理解其与客户目录、组织目录的分工以及隐私保护机制。

一、SAMPLE_CONSULTING 在 LifeOS 工作区中的位置

LifeOS 的用户数据树按领域划分为多个顶层目录，其中 WORK/ 存放日常业务工作上下文：咨询项目、客户关系，以及你在一个或多个商业实体下开展的工作。它明确了BUSINESS/与WORK/的分工：

• BUSINESS/<COMPANY>/描述公司是什么——实体记录、成立文件、税号、AOS（年度经营系统）；
• WORK/<MY_ORG>/描述公司日常做什么——运营文档、设计资产、内部参考；
• WORK/SAMPLE_CONSULTING/描述你的咨询实践本身——你卖什么、复用哪些模板、当前有哪些提案和 SOW 在推进。

该目录在标准安装中作为一个带provenance: template标记的示例模板存在（见 模板文件头部）。LifeOS 与 Pulse 会读取USER/WORK树，使数字助手能以真实数据而非泛泛建议回答业务问题，因此目录内容的准确度直接决定 DA 回答质量。

二、目录结构：咨询实践该放什么

SAMPLE_CONSULTING/README.md 明确规定了四类内容：

这与同级目录形成互补：SAMPLE_CUSTOMER/ 按"一个客户一个子目录"存放合同、交付物、会议纪要等客户专属记录；MY_ORG/ 存放组织内部（非客户、非咨询专属）的运营与品牌资产。咨询实践的"产品与销售层"落在 SAMPLE_CONSULTING，"交付与关系层"落在客户目录，二者配合使用。

推荐的目录骨架

将模板目录重命名后，一个完整咨询实践目录通常长这样：

Consulting/ ├── Offerings/ │ ├── Security_Assessment.md │ ├── Advisory_Retainer.md │ └── Workshop.md ├── Templates/ │ ├── Proposal_Template.md │ ├── SOW_Template.md │ └── NDA_Template.md ├── Acme_Assessment_Proposal.pdf # 进行中的提案 └── Case_Studies/

三、需要填充的字段：把你的实践"说"给 DA 听

模板给出了五个待填充的业务字段，全部标注为(interview — ...)占位符，意味着应通过/interview对话式填充或用真实值直接替换：

1. Practice name（实践名称）——例如 "Independent Security Advisory"，应与日常对话中的称呼一致；
2. Primary offerings（核心服务）——列出 2–4 项服务；
3. Typical engagement size（典型项目规模）——持续时间与金额区间；
4. Ideal customer profile（理想客户画像）——公司规模、行业、对接角色；
5. How you find new work（获客方式）——转介绍、主动咨询、人脉、市场平台。

这些字段的价值在于：DA 回答"该给谁做提案""报价区间多少""优先级如何排"时，依据的是你填写的真实数字与描述，而不是通用话术。

四、使用步骤：从模板到可用目录

模板给出了四步操作流程：

1. 重命名目录为你在对话中习惯称呼咨询实践的名字（如Consulting/、Advisory/）；
2. 创建Offerings/并逐项服务添加文件；
3. 创建Templates/放入可复用的提案 / SOW / NDA 模板；
4. 投放活跃提案——新提案一进来就直接放到本目录。

两种填充途径（与 WORK/README.md 一致）：运行/interview并选择 WORK 范围，让 DA 以对话方式引导填充；或直接编辑文件，把所有(interview — ...)占位符替换为真实值，同时把SAMPLE_*/MY_*目录改成真实名称。

一个填充示例

以目录Consulting/为例，字段填充后大致为：

- **Practice name:** Independent Security Advisory - **Primary offerings:** 安全评估、顾问订阅、安全工作坊 - **Typical engagement size:** 4–8 周，$15k–$60k - **Ideal customer profile:** 50–500 人 SaaS 公司，CISO / CTO 对接 - **How you find new work:** 转介绍 60%、行业活动人脉 25%、官网入站 15%

五、隐私与数据保护：敏感信息只进私有树

模板在 Privacy 一节 明确声明：活跃提案文档可能包含客户名称、项目范围与定价，本目录属于私有 USER/ 树，不会包含在 LifeOS 公共发布物中。同级目录 SAMPLE_CUSTOMER/README.md 与 MY_ORG/README.md 也做出了同样的隐私承诺。

这一承诺在源码层面有据可查：钩子库 egress-class-core.ts 中的数据出口分类规则将LIFEOS/USER/WORK/下（含CUSTOMERS、YOUR_COMPANIES、SAMPLE_CUSTOMER、SAMPLE_CONSULTING）的路径统一归为RESTRICTED类别。也就是说，该目录不仅"不随公共版本发布"，在数据出口侧同样受出口分类保护，客户名称、合同金额、项目细节均保持本地私密。实操建议：把税号、账号、财务数字等敏感实体信息留在私有树内，而不是放进任何文档或技能文件中（参见 YOUR_COMPANIES/README.md 的隐私说明）。

六、与 LifeOS 生态的联动

把 SAMPLE_CONSULTING 填充为真实咨询实践后，它就成为了业务上下文闭环的一部分：

• 数字助手（DA）：通过 WORK/README.md 说明的机制读取USER/WORK树，回答"我的管道怎么样""哪些提案还开着""这周该优先做什么"——答案基于真实客户名与真实数字；
• /interview 工作流：/interview命令支持选择 WORK 范围，以对话形式引导逐项填充，无需手动编辑大量占位符；
• 工作系统绑定（Work System）：若启用仓库绑定，work-config.ts 会加载USER/WORK/config.yaml与work_repo.json，驱动看板渲染与工作捕获——不过这是工作追踪侧的配置，与咨询实践目录本身解耦，是否启用不影响目录作为上下文资料库发挥作用。

七、最佳实践小结

• 一个客户一个目录：不要把多个客户塞进同一目录，DA 依靠目录边界区分项目（见 WORK/README.md 的 Conventions）；
• 目录名用真实称呼：与你在对话中的说法保持一致，便于 DA 建立语义关联；
• 合同与提案贴近工作存放：方便 DA 找到上下文；
• 占位符全部替换干净：所有(interview — ...)都应被真实值取代，避免 DA 读到残留模板内容；
• 敏感信息留在私有树：客户名、合同值、项目细节全部本地保存，由出口分类规则与发布排除机制双重保护。

按照上述步骤，你就能把 SAMPLE_CONSULTING 从示例模板改造为一个真实可用的咨询业务上下文库，让 LifeOS 的每个业务问答都建立在你的真实数据之上。

【免费下载链接】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