背景
最近在思考 anima 的定位时，一个容易滑向的方向是：把它理解成企业 AI native 转型工具，用来解决企业里的潜知识传承问题。例如具身数据生产、量化交易、数据平台、业务流程等场景中，agent 如果感知不到历史经验、领域黑话、隐含标准和踩坑记录，就会反复犯错。
这个方向是成立的，但我认为它不应该成为 anima 的唯一定位。潜知识不可感知的问题并不只存在于企业。个人知识库、开源项目、研究项目、创作项目、量化系统、机器人数据生产、课程学习、家庭长期计划，都会遇到类似问题：
人和项目在长期实践中形成了很多隐性理解，但新进入的 agent 看不到这些理解，因此每次都像从零开始。
所以我更倾向于把 anima 定位成一个通用项目：
anima 是一个 project memory seed protocol：它帮助任意长期工作空间把人的经验、决策、惯例、踩坑和判断标准，逐步沉淀成 agent 可感知、可引用、可验证、可演化的环境。
核心问题
当前很多 agent 工具关注的是：
- 模型能力
- prompt 技巧
- 工具调用
- 多 agent 编排
- 代码生成效率
但真实长期项目里的关键瓶颈经常不是模型不会写代码，而是 agent 缺少项目记忆：
- 不知道为什么当初做了某个架构选择
- 不知道哪些方案历史上已经失败过
- 不知道领域专家看到什么信号会判断输出不可信
- 不知道项目里哪些规则是硬约束，哪些只是偏好
- 不知道某个目录、文件、流程背后承载了什么历史
- 不知道什么时候应该继续执行，什么时候应该升级给人
这类知识往往不是显性的 API 文档，而是潜知识：经验、判断、惯例、黑话、反例、组织记忆、项目品味。
因此 anima 需要解决的问题可以重新表述为：
如何让一个项目把自己长期形成的潜知识，转化为 agent 可感知、可执行、可反馈、可演化的项目环境？
为什么不应该只服务企业
企业是这个问题的高强度场景，但不是唯一场景。
1. 个人知识库也有潜知识
例如 Obsidian vault 中，一个人的知识组织方式、命名习惯、摘录标准、主题演化、原文保留原则、输出风格，都是潜知识。
agent 如果不知道这些，就会把知识库整理成泛泛的二手总结，破坏原有结构。
2. 开源项目也有潜知识
开源项目中的维护者偏好、历史设计决策、贡献规范、架构边界、被拒绝过的方案、测试习惯，很多都没有完整写在 README 中。
agent 如果不知道这些，就会提交看似能跑、但不符合项目精神的 PR。
3. 研究项目也有潜知识
研究中的负结果、失败实验、数据处理细节、指标陷阱、实验复现约束，往往比最终论文更重要。
agent 如果看不到这些，很容易重复错误实验，或者过度相信漂亮但不可靠的结果。
4. 创作项目也有潜知识
长期写作、课程设计、播客制作、内容品牌，也会形成稳定的主题、语气、判断标准、素材使用规则。
agent 如果没有项目记忆，就只能生成平均化内容。
5. 专业系统也有潜知识
量化交易、具身数据生产、数据平台、仿真系统、标注系统，确实是典型场景。但它们应该是 anima 的 domain profile，而不是 anima 的全部。
建议的定位
我建议把 anima 的定位从：
coding agent harness initializer
扩展为：
project memory seed protocol for human-agent collaboration
或者中文：
面向人机协作的项目记忆种子协议。
这个定位下，代码仓库只是第一类 workspace，企业领域只是高阶场景之一。
更通用的 workspace 包括：
- code repo
- Obsidian vault
- research project
- open-source project
- data production pipeline
- quant strategy system
- writing / publishing workspace
- company domain knowledge base
通用抽象：project memory seed
不管场景如何，anima seed 需要提供的不是固定模板，而是一组最小生长机制。
1. Entry Map
告诉 agent：这个 workspace 是什么、当前状态如何、应该先读哪里。
当前可以对应：
2. Architecture / Structure Map
告诉 agent：这个 workspace 的结构如何组织，关键边界在哪里。
代码项目里是：
Obsidian 里可能是：
00-meta/KNOWLEDGE_ARCHITECTURE.md
企业领域里可能是：
domains/<name>/DOMAIN_MAP.md
3. Decision Memory
记录高成本、不可逆、会影响未来判断的选择。
这不只是 ADR，也可以包括：
- 为什么不用某个方案
- 为什么某个指标不可信
- 为什么某类数据要剔除
- 为什么某种写作风格被确定下来
4. Conventions
记录从实践中长出来的惯例。
不是一开始规定一堆规则，而是当某个模式被证明值得重复时，再沉淀成 convention。
5. Pitfalls / Negative Knowledge
这是目前 seed 里还不够显式，但我认为非常关键的部分。
项目记忆不只应该记录“我们怎么做”，还应该记录：
- 哪些事不要做
- 哪些方案试过失败了
- 哪些结果看起来对但其实错
- 哪些错误 agent / 新人特别容易重复犯
负知识是潜知识传承的核心。
6. Playbooks
把可重复任务沉淀成操作路径。
例如：
- 如何开始一次 agent coding session
- 如何处理一篇 podcast transcript
- 如何实现并验证一个量化策略
- 如何筛选具身轨迹数据
- 如何准备一次 release
7. Evals / Checks
如果某条潜知识很重要，就不应该永远停留在 Markdown。
它应该逐步升级为：
经验 → pitfall → checklist → eval case → checker / linter / validation gate
这也是 project memory 从“可读”走向“可验证”的关键。
可能的 profile 方向
为了保持 anima 通用，同时避免抽象过空，可以考虑 profile 机制。
anima init --profile code
anima init --profile obsidian
anima init --profile research
anima init --profile open-source
anima init --profile domain
但 profile 不应该是重模板。它们应该只是不同 workspace 的 seed variant：
- 初始化最小结构
- 放入对应的 entry map
- 给出适合该领域的 growth protocol
- 保留从实践中继续生长的空间
也就是说：
profile 是不同土壤的种子，不是不同风格的装修模板。
对当前 anima 的具体建议
1. 保持核心极小
不要太早做复杂平台、daemon、数据库、MCP、企业 SaaS。
当前最强的地方就是“seed, not template”。一旦过早平台化，很容易背离这个精神。
2. 把 anima check 做成项目记忆健康检查
不只是检查文件是否存在，而是检查：
- 是否有结构说明
- 是否有决策沉淀
- 是否有 conventions
- 是否有 pitfall / negative knowledge
- 是否有 playbook
- 是否有 eval / check
- 哪些部分 dormant
- 哪些知识可能过期
3. 增加 anima remember
让人或 agent 可以低摩擦沉淀项目记忆：
anima remember decision "..."
anima remember convention "..."
anima remember pitfall "..."
anima remember lesson "..."
这比只靠 agent 自觉更新 Markdown 更可靠。
4. 增加 anima session
为一次 agent session 生成 briefing：
anima session --task "..."
它应该告诉 agent：
- 当前 workspace 状态
- 相关文档
- 相关决策
- 常见坑
- 本次任务应该遵守的 playbook
- 完成后是否需要沉淀新知识
5. 显式支持 negative knowledge
建议把 PITFALLS 或 lessons/ 作为一等公民。
很多项目真正有价值的不是“最佳实践”，而是“不要再犯这些错”。
6. 明确从文档到机制的升级路径
anima 不应该只鼓励写文档，还应该鼓励把稳定知识升级为机制：
convention → linter
pitfall → eval case
checklist → CI gate
playbook → CLI workflow
这是让 agent 真正不再重复犯错的关键。
需要讨论的问题
- anima 的核心对象应该叫 project、workspace，还是 something else？
- 当前 seed 是否应该加入
PITFALLS.md 或 docs/lessons/？
anima init --profile ... 是否会背离 “seed, not template” 的精神？如何避免？anima remember 应该只是生成 Markdown，还是维护结构化 metadata？anima check 应该检查到什么程度？只检查结构，还是尝试做语义健康检查？- 如何平衡通用性和具体场景可用性？
- 对 Obsidian / research / open-source / enterprise domain 这些场景，是否应该先做哪个 profile？
- negative knowledge 是否应该成为 anima 的核心概念之一？
- anima 是否应该保持 CLI-only，还是未来需要 background observer / GitHub integration？
- 如何证明 anima 真的让 agent 越用越懂项目，而不是只是多生成了一些文档？
一个可能的北极星指标
我认为 anima 的长期价值不应该用“生成了多少文件”衡量，而应该用：
agent 是否越来越少重复犯这个项目已经纠正过的错误。
换句话说：
历史坑复犯率下降 = project memory 生效
如果一个项目使用 anima 后，每次人类纠错都能沉淀为未来 agent 可感知的记忆、检查或机制，那么它就真的在生长。
总结
我建议 anima 不要被限定为企业 AI native 工具，也不要只停留在 coding agent harness initializer。
更大的方向是：
anima 是一个通用的 project memory seed protocol，用最小结构帮助任意长期工作空间把潜知识转化为 agent 可感知、可验证、可演化的项目记忆。
企业、具身数据、量化交易只是高价值场景；Obsidian、开源、研究、创作同样成立。
这可能会让 anima 从一个小 CLI，逐步发展成一种新的工作空间协议：
不是给 agent 更多 prompt，而是让项目本身变成 agent 可以学习和成长的环境。
背景
最近在思考
anima的定位时，一个容易滑向的方向是：把它理解成企业 AI native 转型工具，用来解决企业里的潜知识传承问题。例如具身数据生产、量化交易、数据平台、业务流程等场景中，agent 如果感知不到历史经验、领域黑话、隐含标准和踩坑记录，就会反复犯错。这个方向是成立的，但我认为它不应该成为
anima的唯一定位。潜知识不可感知的问题并不只存在于企业。个人知识库、开源项目、研究项目、创作项目、量化系统、机器人数据生产、课程学习、家庭长期计划，都会遇到类似问题：所以我更倾向于把
anima定位成一个通用项目：核心问题
当前很多 agent 工具关注的是：
但真实长期项目里的关键瓶颈经常不是模型不会写代码，而是 agent 缺少项目记忆：
这类知识往往不是显性的 API 文档，而是潜知识：经验、判断、惯例、黑话、反例、组织记忆、项目品味。
因此 anima 需要解决的问题可以重新表述为：
为什么不应该只服务企业
企业是这个问题的高强度场景，但不是唯一场景。
1. 个人知识库也有潜知识
例如 Obsidian vault 中，一个人的知识组织方式、命名习惯、摘录标准、主题演化、原文保留原则、输出风格，都是潜知识。
agent 如果不知道这些，就会把知识库整理成泛泛的二手总结，破坏原有结构。
2. 开源项目也有潜知识
开源项目中的维护者偏好、历史设计决策、贡献规范、架构边界、被拒绝过的方案、测试习惯，很多都没有完整写在 README 中。
agent 如果不知道这些，就会提交看似能跑、但不符合项目精神的 PR。
3. 研究项目也有潜知识
研究中的负结果、失败实验、数据处理细节、指标陷阱、实验复现约束，往往比最终论文更重要。
agent 如果看不到这些，很容易重复错误实验，或者过度相信漂亮但不可靠的结果。
4. 创作项目也有潜知识
长期写作、课程设计、播客制作、内容品牌，也会形成稳定的主题、语气、判断标准、素材使用规则。
agent 如果没有项目记忆，就只能生成平均化内容。
5. 专业系统也有潜知识
量化交易、具身数据生产、数据平台、仿真系统、标注系统，确实是典型场景。但它们应该是 anima 的 domain profile，而不是 anima 的全部。
建议的定位
我建议把 anima 的定位从：
扩展为：
或者中文：
这个定位下，代码仓库只是第一类 workspace，企业领域只是高阶场景之一。
更通用的 workspace 包括：
通用抽象：project memory seed
不管场景如何，anima seed 需要提供的不是固定模板，而是一组最小生长机制。
1. Entry Map
告诉 agent：这个 workspace 是什么、当前状态如何、应该先读哪里。
当前可以对应：
2. Architecture / Structure Map
告诉 agent：这个 workspace 的结构如何组织，关键边界在哪里。
代码项目里是：
Obsidian 里可能是：
企业领域里可能是：
3. Decision Memory
记录高成本、不可逆、会影响未来判断的选择。
这不只是 ADR，也可以包括：
4. Conventions
记录从实践中长出来的惯例。
不是一开始规定一堆规则，而是当某个模式被证明值得重复时，再沉淀成 convention。
5. Pitfalls / Negative Knowledge
这是目前 seed 里还不够显式，但我认为非常关键的部分。
项目记忆不只应该记录“我们怎么做”，还应该记录：
负知识是潜知识传承的核心。
6. Playbooks
把可重复任务沉淀成操作路径。
例如：
7. Evals / Checks
如果某条潜知识很重要，就不应该永远停留在 Markdown。
它应该逐步升级为：
这也是 project memory 从“可读”走向“可验证”的关键。
可能的 profile 方向
为了保持 anima 通用，同时避免抽象过空，可以考虑 profile 机制。
但 profile 不应该是重模板。它们应该只是不同 workspace 的 seed variant：
也就是说：
对当前 anima 的具体建议
1. 保持核心极小
不要太早做复杂平台、daemon、数据库、MCP、企业 SaaS。
当前最强的地方就是“seed, not template”。一旦过早平台化，很容易背离这个精神。
2. 把
anima check做成项目记忆健康检查不只是检查文件是否存在，而是检查：
3. 增加
anima remember让人或 agent 可以低摩擦沉淀项目记忆：
这比只靠 agent 自觉更新 Markdown 更可靠。
4. 增加
anima session为一次 agent session 生成 briefing：
anima session --task "..."它应该告诉 agent：
5. 显式支持 negative knowledge
建议把
PITFALLS或lessons/作为一等公民。很多项目真正有价值的不是“最佳实践”，而是“不要再犯这些错”。
6. 明确从文档到机制的升级路径
anima 不应该只鼓励写文档，还应该鼓励把稳定知识升级为机制：
这是让 agent 真正不再重复犯错的关键。
需要讨论的问题
PITFALLS.md或docs/lessons/？anima init --profile ...是否会背离 “seed, not template” 的精神？如何避免？anima remember应该只是生成 Markdown，还是维护结构化 metadata？anima check应该检查到什么程度？只检查结构，还是尝试做语义健康检查？一个可能的北极星指标
我认为 anima 的长期价值不应该用“生成了多少文件”衡量，而应该用：
换句话说：
如果一个项目使用 anima 后，每次人类纠错都能沉淀为未来 agent 可感知的记忆、检查或机制，那么它就真的在生长。
总结
我建议 anima 不要被限定为企业 AI native 工具，也不要只停留在 coding agent harness initializer。
更大的方向是：
企业、具身数据、量化交易只是高价值场景；Obsidian、开源、研究、创作同样成立。
这可能会让 anima 从一个小 CLI，逐步发展成一种新的工作空间协议：