TELOS身份系统实战：十个文件定义个人上下文完整指南

当你让 AI 帮忙制定计划、评估项目或修改一篇文章时，真正影响结果的往往不是那一句提问，而是它是否知道你的长期目标、工作偏好、已有决定和当前限制。

如果这些背景只存在于过去的聊天记录里，每次换工具、换会话或换模型，都要重新解释一遍。更麻烦的是，聊天记录通常没有明确结构，AI 很难区分哪些内容是长期事实，哪些只是当时的临时想法。

TELOS 是 PAI 体系里解决“AI 如何理解我”的一套身份文件方法。它把个人上下文拆成十个主题，每个主题用一个独立的 Markdown 文件维护。它不是心理测试，也不是要写一份完美自传，而是一种让上下文可读取、可更新、可审阅的文件结构。

本文会从零建立一个最小 TELOS 目录，并说明十个文件分别应该写什么、如何避免互相矛盾，以及如何把它们接入日常 AI 工作流。

一、为什么要把“我是谁”拆成文件

直接告诉 AI“请了解我的情况”几乎没有可执行性，因为“情况”包含很多不同类型的信息：目标会变化，信念相对稳定，项目有明确状态，经验可能来自几年前的失败。

如果所有内容都放进一个 about-me.md，文件很快会变成长篇叙述，更新一处时容易遗漏其他部分。拆成主题文件之后，至少有三个好处：

• 需要规划时优先读取目标和项目，不必加载全部人生经历；
• 某个偏好发生变化时，只更新对应文件；
• 文件可以单独审阅、版本控制和授权，不同任务读取不同范围。

TELOS 的重点不是文件名本身。你可以用中文文件名，也可以减少文件数量。重要的是让每类信息有明确归属，并规定哪些文件是事实、哪些文件是判断、哪些文件只是待探索想法。

二、十个核心文件分别写什么

1. MISSION.md：我长期想贡献什么

使命不是一句宏大的口号，而是帮助你判断取舍的长期方向。它回答“我希望通过什么方式，为谁创造什么价值”。

# Mission

## 当前版本
我希望通过长期写作和工具实践，帮助普通开发者更低成本地理解并使用 AI。

## 判断标准
- 是否解决了真实问题？
- 是否能被读者复现？
- 是否积累了可持续的能力？

## 暂不追求
- 为了追热点而放弃事实核验
- 只追求短期曝光而不沉淀方法

使命可以修改，但不要每天改。它应该在面对多个方向时提供稳定参照。

2. GOALS.md：未来一段时间要达成什么

目标要比使命具体，最好带有时间范围、结果描述和当前状态。不要只写“变得更好”或“提高效率”，而要写成可观察的结果。

# Goals

## 未来 12 个月
- 完成一套可持续更新的 AI 工程文章体系
- 建立可复用的内容生产和验收流程

## 本季度
- 发布 12 篇可独立阅读的技术文章
- 为常用工作流补齐输入、输出和验收标准

## 当前优先级
1. 稳定产出
2. 提高事实核验质量
3. 再扩展自动化范围

目标文件应该经常回顾，因为它直接决定 AI 给建议时的优先级。

3. PROJECTS.md：正在做哪些具体事情

项目是目标的可执行载体。每个项目至少写清状态、下一步、阻塞点和完成标准。

# Projects

## 博客内容系统
- 状态：进行中
- 目标：建立从选题到发布的可复用流程
- 下一步：整理文章质量检查脚本
- 阻塞：部分外部事实需要逐条核对
- 完成标准：新文章可独立阅读并通过格式检查

## 个人知识库
- 状态：探索中
- 下一步：确定长期保留的资料类型

项目文件能防止 AI 把“想过的事情”误当成“正在执行的计划”。

4. BELIEFS.md：哪些原则会影响我的选择

信念不是要说服别人接受的观点，而是你在做决定时反复采用的判断原则。例如，你可能相信可验证性优先于新奇感，相信长期积累优先于短期数量。

每条信念最好写上适用范围，避免它变成绝对规则：

# Beliefs

## 可验证性优先
在技术文章中，无法复现的能力和性能结论不应写成事实。
适用范围：公开发布的技术内容。

## 先做小实验
在投入复杂工程之前，先用最小样本验证关键假设。
例外：涉及数据安全的实验必须先完成权限评估。

5. MODELS.md：我用什么框架理解问题

思维模型是你常用的分析工具，例如成本收益、约束理论、二八原则、第一性原理或假设验证循环。不要只罗列名词，要写清什么时候使用以及容易误用的地方。

# Models

## 假设 -> 实验 -> 测量 -> 迭代
适用：工具选型、流程改进和性能判断。
使用方式：先写假设，再定义可观测指标，最后记录结果。
常见误用：只做实验，不提前定义成功标准。

6. STRATEGIES.md：我倾向于如何做事

策略比信念更接近行动。它可以描述你处理复杂任务时的顺序，比如先拆分问题、先处理阻塞项、先建立可回滚版本。

# Strategies

## 复杂任务先建立最小闭环
1. 明确输入和输出
2. 用最小样本跑通
3. 加入验证和日志
4. 再扩大规模

## 写作先事实后表达
先核对来源和边界，再决定标题、结构和语气。

7. NARRATIVES.md：哪些经历塑造了现在的判断

叙事文件不是写鸡汤，而是保存重要经历与它对当前选择的影响。它可以帮助 AI 理解你为什么对某些风险敏感，或者为什么更愿意采用渐进式方案。

# Narratives

## 一次失败的自动化项目
当时直接把所有步骤交给自动化，没有设计中间产物和回滚点。
当前影响：新工作流必须先保留草稿、日志和人工确认点。

只记录真正影响决策的经历，不要把完整人生简历放进上下文。

8. LEARNED.md：已经验证过的教训

教训应该来自具体结果，而不是泛泛而谈。每条记录最好写“发生了什么、原因是什么、以后改变什么”。

# Learned

## 2026-07：一次文章返工
- 现象：文章内容完整，但引用链接有一处失效
- 原因：写作完成后没有单独跑链接检查
- 改进：把官方链接验证加入发布前清单
- 状态：已加入流程，待连续验证三次

教训和信念不同：信念指导选择，教训来自具体结果，两者不要混在一起。

9. CHALLENGES.md：当前阻碍是什么

挑战文件让 AI 看见你暂时解决不了的问题，而不是只看见理想目标。它可以记录约束、风险、待决定事项和需要外部帮助的地方。

# Challenges

## 内容生产速度不稳定
- 影响：计划容易延期
- 可能原因：选题、核验和排版没有拆开
- 已尝试：建立交接稿
- 下一步：统计每个阶段的实际耗时
- 需要避免：在没有数据前宣称某个流程更高效

10. IDEAS.md：值得探索但还没承诺的想法

想法文件是“停车场”。它能防止新念头打断当前目标，也防止有价值的方向因为暂时没时间而丢失。

# Ideas

## 文章质量评分器
- 想解决：减少格式和引用遗漏
- 最小实验：先检查标题、标签、链接和代码块
- 预期投入：半天
- 是否进入当前目标：待评估

想法没有进入项目之前，不要让 AI 把它当成已经批准的任务。

三、推荐的目录和索引文件

可以把十个文件放在一个身份目录里：

USER/
└── identity/
    ├── MISSION.md
    ├── GOALS.md
    ├── PROJECTS.md
    ├── BELIEFS.md
    ├── MODELS.md
    ├── STRATEGIES.md
    ├── NARRATIVES.md
    ├── LEARNED.md
    ├── CHALLENGES.md
    └── IDEAS.md

再添加一个 INDEX.md，写清文件用途和读取优先级：

# Identity Index

## 默认读取
MISSION.md
GOALS.md
PROJECTS.md
STRATEGIES.md

## 需要相关任务时读取
BELIEFS.md
MODELS.md
LEARNED.md
CHALLENGES.md

## 通常按需读取
NARRATIVES.md
IDEAS.md

这个索引非常有用。不是每次写一个标题都需要读取你的全部经历，也不是每次规划项目都要加载所有想法。

四、如何在文件里处理冲突

个人上下文一定会冲突：目标可能改变，项目可能取消，旧策略可能不再适用。最危险的做法是让 AI 自己猜哪条是真的。

建议采用四条规则：

用日期区分新旧

长期文件中的重要内容加上更新时间。没有日期的旧判断很容易被误认为当前状态。

用状态区分事实和候选

使用“当前、已完成、暂停、取消、待确认”等状态，而不是只写一句结论。

让更具体的文件覆盖更抽象的文件

例如，BELIEFS.md 里的“尽量自动化”是一般原则，而 PROJECTS.md 里的“此项目所有公开发布必须人工确认”是具体约束。在项目任务中，具体约束优先。

无法判断时先提问

AI 不应该擅自把两条矛盾信息合并成一个新结论。应输出冲突位置、可能影响和需要你确认的问题。

五、让 AI 正确读取 TELOS

可以在上下文入口文件中写一份简单规则：

# Context Loading Rules

1. 先读取 identity/INDEX.md。
2. 根据任务只加载相关文件。
3. 将 GOALS、PROJECTS 和 CHALLENGES 视为当前状态来源。
4. 将 BELIEFS、MODELS 和 STRATEGIES 视为决策参考，而非硬性事实。
5. 对存在日期冲突的内容报告冲突，不要自行覆盖。
6. 未经确认不得修改长期身份文件。

如果你使用的是支持项目上下文文件的 Agent，可以在项目入口引用 INDEX.md；如果使用普通聊天工具，可以在每次任务开始时只提供与任务相关的文件。关键不是“永远加载全部内容”，而是建立稳定的加载规则。

六、如何更新而不把文件写乱

建议把“读取”和“写入”分开：

• 读取身份文件可以作为普通任务的前置步骤；
• 修改身份文件必须先输出修改草案；
• 重要变更要保留日期、原因和来源；
• 每隔一段时间人工清理重复、过期和互相矛盾的内容；
• 用 Git 或其他版本系统保存变更记录。

一个更新请求可以这样写：

请检查本次对话是否产生了值得进入 TELOS 的长期信息。

只允许提出候选更新，不直接修改文件。
对每条候选信息输出：
- 建议写入的文件
- 原始证据
- 为什么值得长期保留
- 可能与哪些已有内容冲突
- 建议的 Markdown 文本

这种做法比“每次对话自动记住一切”更可控，也更容易发现模型的误读。

七、隐私边界和备份策略

TELOS 会包含比普通项目文档更私人的信息。至少要做到：

• 不把真实身份、联系人、财务和密钥放在同一个可共享目录；
• 对外部模型只提供完成当前任务所需的最小上下文；
• 日志和版本库中不保存访问令牌、密码和私人附件；
• 备份前检查是否包含不应同步的文件；
• 删除信息时同步检查缓存、导出文件和历史版本。

如果你不确定某条信息是否应该被模型长期保存，默认把它放在临时上下文中，而不是写入 TELOS。长期记忆的价值来自筛选，而不是数量。

八、七天建立第一版 TELOS

第一天写 MISSION.md 和 GOALS.md，先用当前真实情况，不追求漂亮。

第二天写 PROJECTS.md，只列正在进行的项目，并给每个项目补一个下一步。

第三天写 BELIEFS.md 和 STRATEGIES.md，记录过去确实影响过你决策的原则。

第四天写 MODELS.md 和 LEARNED.md，每个文件先放三条。

第五天写 CHALLENGES.md 和 IDEAS.md，把阻碍和想法从脑中移出来。

第六天整理 NARRATIVES.md，只保留能解释当前选择的经历。

第七天创建 INDEX.md，规定默认加载哪些文件，并让 AI 根据一个真实任务试读一次。

结论

TELOS 的核心不是“写十个文件”，而是把个人上下文从聊天记录里拆出来，变成可读取、可更新、可验证的知识资产。

最小版本不必完整：使命、目标、项目、工作方式和一份索引，就足以改善很多任务。随着你不断做决定、获得反馈和遇到新挑战，再把稳定的信息沉淀到对应文件。

PAI 的公开实现和命名会随项目演进变化。本文参考 Daniel Miessler 的公开 LifeOS 仓库整理出通用的 TELOS 文件方法，实际接入时应以当前工具的上下文加载机制和权限模型为准。