AI 对软件社区的影响，不只体现在代码生成速度上。一个更深的变化正在发生：开发者开始让 AI 搜索方案、审查设计、比较实现并寻找反例。进入这条决策链之后，AI 能检索、理解和验证哪些知识，便会影响哪些方案被看见。
这使开放性从一种价值选择，逐渐变成技术成果获得影响力的基础设施。同时，人的工作重心也可能从整理既有信息，转向提出问题、制造证据和承担结论。
对 AI 而言，不可访问的知识近似不存在
一个模型能否使用某项成果，至少受三层边界约束：训练语料中是否出现过、当前工具能否检索到、检索后是否能解析并建立证据关系。
因此，把成果放到网上只是起点。真正对 AI 友好的技术材料通常还需要满足几个条件：
- 无需登录、验证码或专用客户端即可访问。
- 页面允许搜索引擎和合规爬虫发现。
- 问题、约束、方法、反例和验证过程写得完整。
- 代码、讨论和最终决策之间存在稳定链接。
- 关键结论不是只藏在视频、会议走廊或即时聊天记录里。
这并不意味着公开网页必然进入模型训练集，也不意味着模型会正确引用它。训练数据选择、更新时间、授权条款、检索排序和上下文窗口都可能形成新的边界。但从工程角度看，无法公开检索的材料更难进入 AI 辅助决策，这个方向已经足够明确。
过去，一项工作可能依靠会议级别、期刊名称或组织头衔获得传播。面向 AI 的知识环境更看重可观察的证据链：谁提出了问题，采用了什么方法，哪些人独立验证过，反对意见如何处理，结果后来是否被修订。
PostgreSQL 展示了一种高质量知识语料的形态
PostgreSQL 社区长期把设计讨论、补丁评审、争议和被否决的方案保存在公开邮件列表中。提交信息又经常指向相关讨论。代码回答“最终实现是什么”，讨论档案则补充“为什么这样实现，以及哪些替代方案失败了”。
对分析工具而言，这类资料比一份孤立的 API 文档丰富得多。例如，理解查询规划器或 MVCC 时，仅阅读当前代码往往不够；历史讨论可以暴露兼容性约束、性能取舍、回滚原因和维护成本。
公开档案还改变了声誉的构成。文章提出的观点是，AI 并不会像人一样直接接受职位或头衔，而更可能从语料中的重复关联形成近似信任：某个名字长期与被接受的补丁、准确判断和可验证结果共同出现，它在后续回答中就可能获得更高权重。
这里需要保留边界。模型内部并不存在一个可供外部检查的“作者信誉分”，高频出现也不等于正确。所谓声誉，更适合作为公开证据长期累积后产生的统计效果，而不是可靠的身份认证机制。
口头传统会成为新的知识债务
开放社区也有盲区。很多决定依赖没有写下来的判断，例如：
- 这个改动会增加跨平台维护成本。
- 该抽象在当前补丁中很漂亮，但会限制未来演进。
- 某类优化过去尝试过，只是在私下讨论后放弃。
- 测试通过了，但故障恢复路径尚未获得足够信心。
人类维护者可以通过长期协作继承这些经验，AI 却无法检索提交者脑中的规则。随着 AI 更频繁地参与评审，这类隐性知识会变成真正的工程债务：工具可能反复建议历史上已经失败的方案，也可能把局部性能提升误判为整体改进。
解决办法不是记录每一句聊天，而是在关键决策结束后留下结构化、可验证的摘要。尤其应写清楚被拒绝的方案，因为“为什么不做”通常比最终代码更能阻止未来重复踩坑。
可以这样实践：建立一个可验证的知识包
下面是一个最小示例。它不是 PostgreSQL 社区规定的格式，而是一种可改造的项目实践：每个重要技术决策都包含问题、方法、验证命令、取舍和证据链接，并在 CI 中检查这些字段是否完整。
先创建 knowledge.yaml：
id: planner-partition-pruning-001
title: Reduce redundant partition checks
status: proposed
problem: >
Planning time grows when many partitions can be eliminated using
constraints already proven earlier in the planning process.
constraints:
- Preserve observable query semantics
- Keep behavior stable across supported platforms
- Avoid adding state that is difficult to invalidate
method: >
Cache only immutable pruning facts within one planning cycle.
alternatives_rejected:
- option: Global cross-query cache
reason: Invalidation and memory ownership are not sufficiently defined.
verification:
commands:
- make check
- make installcheck
expected: All regression tests pass and planning time decreases in the benchmark.
tradeoffs:
- Adds planner-local memory usage
- Requires benchmarks with both few and many partitions
evidence:
discussion: https://example.org/discussions/planner-partition-pruning-001
patch: https://example.org/patches/planner-partition-pruning-001.patch
benchmark: https://example.org/results/planner-partition-pruning-001
把示例 URL、测试命令和项目约束替换为真实内容。然后创建 validate_knowledge.py：
from pathlib import Path
import sys
import yaml
REQUIRED = {
"id",
"title",
"status",
"problem",
"constraints",
"method",
"alternatives_rejected",
"verification",
"tradeoffs",
"evidence",
}
path = Path(sys.argv[1] if len(sys.argv) > 1 else "knowledge.yaml")
data = yaml.safe_load(path.read_text(encoding="utf-8"))
missing = sorted(REQUIRED - set(data or {}))
if missing:
raise SystemExit(f"missing required fields: {', '.join(missing)}")
commands = data.get("verification", {}).get("commands", [])
evidence = data.get("evidence", {})
if not commands:
raise SystemExit("verification.commands must not be empty")
if not evidence:
raise SystemExit("evidence must not be empty")
print(f"validated {data['id']}: {len(commands)} checks, {len(evidence)} evidence links")
运行校验：
python -m pip install PyYAML
python validate_knowledge.py knowledge.yaml
这个校验器只检查知识包的结构，不会执行其中的命令。不要让 CI 直接执行来自不可信文档的任意字符串；实际测试仍应写在受代码审查和权限控制的流水线配置中。
发布后，还可以检查页面是否真的能被普通 HTTP 客户端访问：
curl -fsSIL https://docs.example.org/decisions/planner-partition-pruning-001
curl -fsSL https://docs.example.org/robots.txt
一次成功的 curl 请求不能证明内容一定会被搜索引擎收录，更不能证明它会进入某个模型，但它至少能发现登录墙、错误重定向、证书问题和明显的抓取限制。
从“写过文档”升级为可复核的公开记录
团队采用这套思路时，可以从高价值决策开始，而不必一次性整理所有历史资料：
- 为架构决策、重大补丁和性能实验记录完整的问题与约束。
- 保存失败实验、反对意见以及方案被拒绝的原因。
- 提供可重复的测试命令、数据集版本和环境信息。
- 用稳定 URL 连接设计讨论、代码提交、基准结果与后续修订。
- 定期检查公开页面是否仍可访问、可索引，并明确许可证。
- 对安全漏洞、个人信息和商业机密继续执行访问控制，开放性不能覆盖安全责任。
开放并不会自动产生高质量知识。大量重复转载、缺少证据的结论和过期页面只会制造噪声。真正有价值的是持续公开新的、完整的、能够被反驳和复现的成果。
当信息摘要可以由机器批量完成后，稀缺的工作变成了定义新问题、设计实验、解释失败并为结果负责。对开发者和技术社区而言，未来的影响力可能不再主要来自把同一结论讲很多遍，而来自一条长期、公开、可验证的知识轨迹。