这套提示词的核心目的，是把一次性的 agent 编程过程，逐步沉淀成一种近似 harness 编程的项目协作方式。 需要这么做的根本原因是：大模型本身是无状态的。Codex 在一个上下文窗口里可以理解项目、推理链路、排查问题、形成判断；但这个上下文一结束，很多理解就会消失。换一个线程、换一个 agent，甚至隔一段时间重新进入同一个项目，如果没有外部化的项目上下文，就必须重新扫描、重新猜测、重新踩坑。 但它也有明显局限：这还不是完整的自动化 harness。它解决得比较好的是工作环境和上下文持久化，但反馈回路仍然依赖大模型本身执行：输入如何拆解、检查是否充分、问题是否问得对、验证结果如何解释，仍然需要模型消耗推理和上下文成本来完成。也就是说，它把“记忆”和“项目地图”从模型里搬到了仓库里，但还没有完全把判断、测试和反馈自动化。 因此，这套提示词更准确地说，是从 agent 编程走向 harness 编程的中间形态：先让项目具备可被 agent 反复读取、修正和增强的上下文骨架，再逐步把其中稳定的检查、验证和部署步骤自动化。 请为当前项目建立一套面向 Codex / LLM 的项目上下文 Wiki，目标是让新的 agent 在不依赖历史聊天记录的情况下，能够快速理解项目结构、运行方式、关键约束、跨模块关系、常见故障、验证方法，以及当前仍然缺失或需要澄清的信息。 请先读取当前仓库文件结构，再按下面格式创建或更新 Markdown 文档。不要编造未知事实；不确定的信息写成“待确认”，并说明需要用什么命令、文件、人员或外部系统确认。 推荐文件结构： - README.md 作为项目上下文入口，说明： - 项目是什么 - 项目为什么存在 - 当前目标 - 成功标准 - 失败标准 - 主要服务对象或使用者 - 文档目录说明 - 推荐阅读顺序 - AGENTS.md 作为 Codex 的持久入口说明，保持简短，说明： - 先读哪些上下文文件 - 修改代码或配置前必须确认哪些约束 - 如何验证工作完成 - 哪些内容不能写入文档，例如密钥、token、密码、私有凭证 - modules/overview.md 列出系统模块索引。每个模块只描述“自己是什么、负责什么、在哪里运行、如何检查、如何重启、有哪些注意点”。 - modules/<module-name>.md 每个文件描述一个模块，建议包含： - 职责 - 部署位置 - 关键路径 - 配置文件 - 启停命令 - 检查命令 - 日志位置 - 已知问题 - 不属于本模块负责的事情 - relationships/overview.md 或 relationships/access-flow.md 描述跨模块数据流、请求链路、调用关系、依赖关系。重点写清： - 用户请求如何进入系统 - 数据如何流转 - 哪些模块影响哪些能力 - 如何判断问题发生在哪一层 - relationships/service-registry.md 作为权威清单，只维护当前真实状态，不写长篇事故过程。建议用表格记录： - 服务名 - 对外入口 - 内部地址 - 运行位置 - 配置文件 - 启停/检查命令 - 日志位置 - 最近验证时间 - 当前认证或安全状态 - constraints/environment.md 记录稳定环境事实和假设，例如： - 操作系统 - 运行环境 - 网络条件 - 目录约定 - 权限限制 - 不能改变的外部依赖 - 待确认事项 - constraints/operations-runbook.md 写可执行运维手册，包含： - 新增一个服务或模块的步骤 - 修改配置后的最小验证 - 常用构建、测试、部署、回滚命令 - 分层排查流程 - 安全检查项 - issues/issues.md 作为历史问题索引。这里只放问题列表、状态、影响和结论。 - issues/<issue-name>-YYYY-MM-DD.md 每个历史问题单独成文，建议包含： - 现象 - 背景 - 当时的错误假设或误解 - 诊断证据 - 处理过程 - 最终结论 - 当前替代方案 - 对现在的影响 - 后续如何避免 - questions.md 记录 Codex / LLM 在理解项目时发现的缺口、矛盾和待澄清问题。 这是持续迭代项目上下文的入口，不是失败产物。 写作规则： 1. 当前真实状态优先于历史记录。 2. 权威表优先于分散模块说明。 3. issue 只记录历史问题，不维护当前端口、当前服务状态或权威配置。 4. 模块文档只解释模块自身，跨模块链路放到 relationships/。 5. 运维命令必须可复制执行；如果命令依赖环境，写明运行位置。 6. 所有验证都要写“预期结果”，不要只写命令。 7. 不要把密码、API key、token、私钥、cookie、UUID、生产凭证写入 Wiki。 8. 不确定内容标记为“待确认”，不要用猜测填充。 9. 如果发现历史 issue 暴露出稳定规则，把规则同步到 modules/、relationships/ 或 constraints/，不要只留在 issue 里。 10. 文档目标是让新的 Codex agent 能根据文档完成修改、运行检查、定位故障并解释判断依据。 理解与疑问处理规则： 1. 默认项目上下文一定存在缺口。不要为了让文档看起来完整而补全未知事实。 2. 发现以下情况时，必须记录为问题： - 文件存在但用途不明确 - 配置项存在但不知道谁读取 - 服务、脚本、端口、目录、环境变量没有来源说明 - 文档之间存在冲突 - 代码行为和现有文档不一致 - 缺少验证命令 - 缺少运行位置 - 缺少负责人、调用方或依赖方 - 历史问题有结论但没有证据 - 当前状态无法从仓库内确认 3. 问题不要散落在对话里，必须汇总到文档中。 4. 新建或维护 `questions.md`，作为“待澄清问题清单”。 5. 每个问题应包含： - 问题描述 - 相关文件或模块 - 为什么这个问题重要 - 当前已知线索 - 建议确认方式 - 优先级：High / Medium / Low - 状态：Open / Answered / Obsolete 6. 如果某个问题被确认，应把结论同步回对应的 `modules/`、`relationships/`、`constraints/` 或 `issues/` 文档，并把 `questions.md` 中的问题状态改为 `Answered`。 7. 如果问题已经不再 relevant，标记为 `Obsolete`，不要直接删除。 请完成以下任务： 1. 扫描当前项目结构。 2. 判断项目中的主要模块、跨模块关系、环境约束、历史问题和待澄清问题。 3. 创建上述目录和 Markdown 文件。 4. 如果已有类似文档，按这个结构重组，保留有效事实。 5. 不要为了完整性编造内容；缺失、冲突、无法确认的信息统一进入 `questions.md`。 6. 最后输出： - 创建或更新了哪些文件 - 当前已经确认的项目理解 - 当前仍待确认的信息 - 已汇总到 `questions.md` 的问题数量和最高优先级问题 - 建议下一次优先补充的上下文 配套的agent.md # Codex 项目上下文规则 开始处理本项目任务前，优先阅读： 1. `README.md` 2. `modules/overview.md` 3. `relationships/service-registry.md` 或 `relationships/overview.md` 4. `constraints/environment.md` 5. `constraints/operations-runbook.md` 6. `questions.md` 7. 需要排查历史问题时再读 `issues/issues.md` 维护规则： - 当前真实状态写入 `relationships/service-registry.md`。 - 单个模块说明写入 `modules/`。 - 跨模块链路写入 `relationships/`。 - 环境事实和可执行运维命令写入 `constraints/`。 - 历史故障、误解修正和处理过程写入 `issues/`。 - 理解缺口、文档矛盾、无法确认的信息写入 `questions.md`。 - 不写入密码、token、私钥、cookie、生产密钥或其他敏感凭证。 - 不确定的信息标记为“待确认”，并写明确认方式。 - 当 `questions.md` 中的问题被确认后，必须把结论同步回对应上下文文档。
web 串口助手 想自己做一个web 串口助手。之前在浏览 阮一峰周刊 的时候，有见到过一个惊艳的 web 串口助手，一直找不到，颇为遗憾。 今天下午，寻找了几个小时的github，发现开源的 web 串口助手 都是功能少了一点，与自己理想的差了一点。 最后终于找到了 云之彼端串口助手 在 阮一峰老师科技爱好者周刊「工具」和「资源」汇总 中找到的。
如何优雅的屏蔽GCC编译器告警 作为一个合格的C语言程序员，在编译代码的时候一定要加上-W和-Wall选项，要保证代码中没有任何的warning信息,提高代码的可靠性。-Wall选项意思是编译后显示所有警告，-W选项只显示编译器认为会出现错误的警告。 但是有些时候，有些功能模块尚待开发，有些函数也没有完成功能，虽然不影响程序的正常执行，但是待开发的代码难免会有warning输出。如果去掉编译选项-W和-Wall，整个工程的告警就都会被忽略掉，那么怎么优雅的屏蔽部分代码的告警呢？ pragma GCC diagnostic ignored "告警类型" 编译如下代码： #include <stdio.h> void print_message(char *str, int num) { printf("%s : %d\n", str, &num); return; } int main(int argc, char *argv[]) { int i, j, k, t; t = 0; for(i = 0; i < 3; i++) { print_message("J value is", j++); } } 编译时加上-Wall选项，会出现如下告警提示： 有我们所学的C语言知识可知： -Wformat=：类型不匹配 -Wunused-but-set-variable：变量赋值却未使用 -Wunused-variable：变量未使用（也没有赋值） -Wreturn-typet：缺少返回值 我记得还有一种告警是"变量使用前未初始化"，代码中变量j就属于这种情况，但是不知为何没有告警信息，可能是我编译器版本的问题，或者是这个不会影响程序运行。 接下来我要屏蔽-Wformat=类型的告警：在函数前加上一行预处理命令，新的代码如下： #include <stdio.h> #pragma GCC diagnostic ignored "-Wformat=" void print_message(char *str, int num) { printf("%s : %d\n", str, &num); return; } int main(int argc, char *argv[]) { int i, j, k, t; t = 0; for(i = 0; i < 3; i++) { print_message("J value is", j++); } } 再次编译： 可以看到，-Wformat=类型的告警被屏蔽掉了。 当然，我们也可以同时屏蔽多种类型的告警，新的代码如下： #pragma GCC diagnostic ignored "-Wunused-but-set-variable" #pragma GCC diagnostic ignored "-Wunused-variable" #pragma GCC diagnostic ignored "-Wformat=" #pragma GCC diagnostic ignored "-Wreturn-type" void print_message(char *str, int num) { printf("%s : %d\n", str, &num); return; } int main(int argc, char *argv[]) { int i, j, k, t; t = 0; for(i = 0; i < 3; i++) { print_message("J value is", j++); } } 编译结果如下： 可以看到，所有的告警信息都被屏蔽掉了。 现在有一个问题，如果这样写的话，那么在这几行之后所有代码的告警信息都会被屏蔽掉，那么我想在某行之后恢复告警，该怎么做呢？切记，push和pop很好用哦，完整代码如下： #include <stdio.h> #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wunused-but-set-variable" #pragma GCC diagnostic ignored "-Wunused-variable" #pragma GCC diagnostic ignored "-Wformat=" #pragma GCC diagnostic ignored "-Wreturn-type" void print_message(char *str, int num) { printf("%s : %d\n", str, &num); return; } int main(int argc, char *argv[]) { int i, j, k, t; t = 0; for(i = 0; i < 3; i++) { print_message("J value is", j++); } } #pragma GCC diagnostic pop
基于FreeRTOS的程序, 在 vTaskStartScheduler() 启动前, 调用 FreeRTOS 的 API, 会屏蔽低于 configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY 的优先级的中断. FreeRTOS 的调度器没有运行, 不要使用其API, 避免不必要的麻烦. [...]
在多线程系统中,一些资源有寄存器,变量,函数,外设都是可以共同访问的.在实际的编程中,会导致数据错乱的问题,本文将捋捋如何管理共享资源. [...]