跨项目开发协作：主线核查、范围约束与证据交付

从用户提供的 AGENTS.md 指令提炼可跨项目复用的开发协作提示词，保留代码审计、权威顺序、分支隔离、最小修改和验证纪律。

提示词发布于 2026-11-09更新于 2026-11-09浏览 0

部分附加信息、来源说明或示例仍显示原文。

来源：import:liubai_public_20261104 · https://github.com/Shanvision-star/liubai-prompt-library/blob/25f0137e36a8fae46aebace86b18cdfeff624a99/bundled-library/entries/PRM-0001/original.md · 授权：使用者确认拥有本条素材的公开转载权或授权；未推断其他作者或许可。

# 留白素材 # 工作流

适用说明

适用场景

留白公开素材集中的用户投稿；原作者及外部许可未另行确认，效果未实测。

公开署名

留白素材库整理

EXAMPLE

使用示例

该主题的原文与优化版共用这份示例。

提示词示例输入

示例需求：在现有内容列表增加状态筛选，保留既有数据和搜索；当前项目只使用一套工作环境。已知列表接口返回状态字段，尚未确认筛选参数是否存在。

文字示意结果

以下结果为人工编写的示意，并非模型实测输出。

先检查现有列表接口、筛选组件和相关文档，确认状态筛选能力是否已存在；只在当前工作树完成必要调整。验证时覆盖全部状态、单一状态和重置操作，并记录未验证的范围。上述步骤是针对虚构需求的示例，不代表已检查任何真实项目。

实际生成时的文字输入

Create one original 2-by-2 sheet of FOUR coherent keyframes for a visual example of a careful software change workflow. Four equal landscape tiles edge-to-edge, no gutters, borders, readable words, text, letters, numbers, logos or people. Fixed overhead desk composition: a laptop with abstract code lines, a small blue folder, a blank checklist card and a pencil. Across frames in reading order, a circular focus marker moves from folder to laptop to checklist, and a final checkmark appears; preserve the desk, camera and object positions. Friendly editorial cut-paper illustration in navy, muted teal, cream and warm amber, clear shapes and soft shadows. This is a conceptual illustration, not a screenshot or actual project result.

查看输入译文

译文仅供参考；实际生成时使用的是上方原文。

创作一张由 2 x 2 组成的包含四个连贯关键帧的原创图表，用于展示一个谨慎的软件变更工作流的视觉示例。四个等大的横向平铺方块，无间隙、无边框、无可读的单词、文本、字母、数字、标志或人物。固定的俯视桌面构图：一台带有抽象代码行的笔记本电脑、一个蓝色小文件夹、一张空白清单卡和一支铅笔。按阅读顺序在帧间移动，一个圆形焦点标记从文件夹移动到笔记本电脑再到清单卡，最后出现一个对勾；保持桌面、相机和物体位置不变。采用海军蓝、柔和青色、奶油色和暖琥珀色的友好编辑风格剪纸插画，形状清晰，阴影柔和。这是一个概念插图，不是屏幕截图或实际的项目结果。

图片与动图示意结果

文件、代码和清单依次被突出显示，示意先核对现状、再修改和验证。

静态图片由 imagegen 按上面的输入生成；动图由生成的四帧画面拼接而成，效果仅供参考。

THE PROMPT

提示词正文

# AGENTS.md 指令

<INSTRUCTIONS>
- 测试
   然后决定该任务是代码缺口、文档缺口、验证缺口还是产品边界决策。

15. 首先使用成本最低的验证方式。
   从证明当前变更的最小测试或检查开始。
   仅在受影响的范围合理时才扩大范围。
   将实际提供商的冒烟测试与默认自动化测试分开。

16. 对于 Python 后端变更：
   - 为新文件添加中文模块文档字符串
   - 仅在解释意图、约束或边界存在原因时使用中文注释
   - 运行相关的 pytest
   - 在更改签名、类型注解、存储库、服务或应用启动路径时，运行导入冒烟测试
   - 避免使用名为 list/dict/tuple/set/type 的类方法，以免遮蔽内置泛型

17. 对于前端变更：
   - 遵循现有的 Next.js / TypeScript / Tailwind 模式
   - 使用现有的 API 客户端和类型
   - 保持权限反馈对用户可见
   - 避免重复现有组件
   - 当变更影响面向用户的 UI 或共享类型时，运行 typecheck/lint/build

18. 对于文档变更：
   - 在修改项目规则时，在编辑前说明“原始 / 修订 / 原因或影响”
   - 即使是仅针对文档的执行计划和项目记忆文件，也要保持分支隔离
   - 当行为或权威发生变化时，同步 README、周文档、工作流和记忆
   - 不要将未来的假设写成已完成的事实
   - 不要编写想象的路径、字段或命令；请先从代码中进行验证

19. 沟通风格：
   除非文件明确使用英文，否则在进行项目推理和文档编写时，默认使用中文工作。
   保持更新简洁。
   对不确定性保持直言不讳。
   如果需求与当前主线冲突，请在实施前解释权衡方案。

20. 完成规则：
   在没有新的验证证据之前，不要声称已完成。
   准确报告已验证的内容以及未验证的内容。
```

---

## 2. 未来项目的可复用记忆

### 记忆 1: 不要过度信任计划，要以代码仓库为准

该项目表明执行计划可能会落后于代码。
第5周最初将几个功能描述为缺失，而代码库中已经包含了 `Insights`、`Comments`、`Favorites`、`/me` 和 `PaperCritiqueAgent` 的实现。

未来的 Codex 行为：

- 阅读计划，然后审计代码。
- 如果计划与代码不一致，首先将工作归类为文档或工作流修正。
- 不要仅仅因为过时的计划称其缺失，就重新构建现有功能。

### 记忆 2: 每个严肃的项目都需要一个权威顺序

一旦权威变得明确，ChatPaperHub 就变得更容易管理：

1. 主线与系统思维文档
2. 工作流规范
3. README
4. 每周文档与审计记录

未来的 Codex 行为：

- 在编辑之前建立权威顺序。
- 将每周执行文档视为历史记录，除非当前的权威文档对其进行了提升。
- 当低级文档与高级文档发生冲突时，更新低级文档，而不是默默遵循它。

### 记忆 3: 在更改前锚定

最佳的项目决策来自于首先询问更改属于哪里。

可复用的锚点：

- 对象层
- 过程层
- 视图层
- 代理层
- 权限边界
- 操作边界
- 文档记忆

未来的 Codex 行为：

- 不要从文件开始。
- 从层、边界和原因开始。
- 然后选择文件。

### 记忆 4: 代理不是按钮

在此项目中，代理（Agent）不是调用模型的前端操作。它是一个具有身份、版本控制、模式（schema）、可观测性和可回放性的可治理生产单元。

未来的 Codex 行为：

- 每个代理必须具备 `agent_name`、`prompt_version`、输入/输出模式、提供者边界、AgentRun 生命周期以及失败记录。
- 代理输出应为结构化资产，而非松散文本。
- 缓存命中可以跳过模型调用，但绝不能擦除运行历史或可审计性。

### 记忆 5: 将模拟测试与真实的提供者冒烟测试分离

默认测试应保持确定性且成本低廉。真实的 LLM 调用很有价值，但它们属于受控的冒烟检查，而不属于常规的本地/CI 基准测试。

未来的 Codex 行为：

- 默认保留 mock/stub 测试。
- 仅在明确验证生产环境价值时，才运行真实的提供者冒烟测试。
- 发生真实调用时，务必记录提供者、模型、Token、延迟和成本。

### 记忆 6: 不要将未来层混入当前任务

ChatPaperHub 反复需要防止过早引入 PDF/RAG、pgvector、多智能体 DAG 运行时、匿名 AI 聊天、企业层、推送/推荐以及反爬虫功能。

未来的 Codex 行为：

- 明确标记未来层想法。
- 不要在当前主线 diff 中实现它们。
- 如果某个未来层想法变得必要，请先更新权威文档和执行计划。

### 记忆 7: 文档是产品界面的一部分

README、工作流文档和周报文档直接影响未来智能体和协作者的行为。陈旧的文档会造成真实的工程浪费。

未来的 Codex 行为：

- 当行为发生变化时，在同一任务中同步文档，或明确记录未同步的原因。
- 当文档被修正时，应包含预期的项目影响，而不仅仅是措辞变更。
- 将记忆文档视为可复用的操作知识，而非装饰性笔记。

### 记忆 8: 分支和编辑门禁不是可选的

本项目暴露了一个流程失败：在创建隔离分支之前就进行了文档编辑，并且在未重新陈述 `[Original] / [Revised] / [Reason / Impact]` 的情况下就写入了一项记忆编辑。

未来的 Codex 行为：

- 将文档执行计划和记忆文件视为受分支限制的工作。
- 在文件编辑之前创建 `codex/` 分支，而不是在发现偏差后才创建。
- 在更改项目规则或记忆之前，展示编辑对比。
- 如果遗漏了分支限制，请如实说明，立即创建纠正分支，并将此次遗漏记录为流程记忆。

---

## 3. 开始新项目的紧凑提示词

在开始一个追求 ChatPaperHub 式纪律的未来项目时，请使用此短提示词：

```text
在编辑之前，构建项目地图：
1. 当前主线是什么？
2. 权威顺序是什么？
3. 此任务属于哪一层？
4. 当前代码中存在什么？
5. 实际差距是什么？
6. 弥补该差距的最小差异是什么？
7. 应该由哪个分支承载它？
8. 在需要时是否已展示编辑对比？
9. 什么验证可以证明它？
10. 必须同步哪些文档或记忆？

然后仅在该边界内行动。
```

---

## 4. 如何使用此记忆

- 对于此仓库：在规划可重用的 Codex 行为时，请在阅读 `agent.md`、主线文档和工作流规范后阅读此文件。
- 对于未来的仓库：将第 1 节复制到 Codex 自定义指令中，然后将 ChatPaperHub 特有的主线和未来层列表替换为该项目自身的等效内容。
- 对于每周规划：在检查计划是否陈旧、过于宽泛或混合层级时，使用第 2 节作为检查清单。

核心教训很简单：

> Codex 不应是陈旧假设的快速打字员。它应该是一个谨慎的项目操作员，负责审计现实、保护主线、进行细微的更改、验证这些更改，并为下一次迭代留下记忆。
</INSTRUCTIONS>

提示词仅供参考，请结合实际场景调整，并核实 AI 生成结果。