961118 - whwu
type: channel
link: https://961118.xyz/index.php/author/1/
description: whwu
items: 从 agent 编程走向 harness 编程的提示词
items: Andrej Karpathy LLM 整理知识系统
items: 谷歌 14 年工作带给我的 21 条经验（转发）
items: AI 多代理大规模编程的尝试
items: 远程执行python脚本
items: 嵌入式软件分层
items: web 串口助手
items: 如何优雅的屏蔽GCC编译器告警
items: GitHub Pages 与 Cloudflare Pages：写博客和部署网站的最佳平台
items: 大模型的训练速度正在加快

从 agent 编程走向 harness 编程的提示词
type: item
date: 2026-07-09T14:42:15+08:00
description: 这套提示词的核心目的，是把一次性的 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. 不要把密码…

Andrej Karpathy LLM 整理知识系统
type: item
date: 2026-04-06T21:47:38+08:00
description: Andrej Karpathy LLM 整理知识系统 LLM 知识库 Andrej Karpathy 最近发现一件非常有用的事情：用大语言模型（LLM）为各种研究主题构建个人知识库。这样一来，最近的大量 token 使用不再主要用于操作代码，而是更多用于处理知识（以 markdown 和图片形式存储）。最新的 LLM 在这方面已经做得相当不错。具体来说： [...]

谷歌 14 年工作带给我的 21 条经验（转发）
type: item
date: 2026-01-26T13:49:00+08:00
description: 21 Lessons From 14 Years at Google 转发分享 2026年1月3日 大约 14 年前加入谷歌时，我以为这份工作就是写出优秀的代码。我只对了一部分。随着待的时间越长，我越发意识到：那些茁壮成长的工程师未必是编程技术最好的，而是那些懂得如何驾驭代码之外一切事物的人——包括人、政治、目标对齐以及模糊性。 这些是我希望自己能早点知道的经验教训。有些本来可以帮我省去几个月的挫折，有些则花了我好几年才完全领悟。这里没有关于具体技术的建议——技术变化太快，并不重要。这些经验关于那些在不同项目、不同团队中反复出现的模式。 我分享这些是因为我曾从那些为我指路的前辈工程师那里受益良多。就把这当作我的一次薪火相传吧。 1. 最优秀的工程师痴迷于解决用户问题。 爱上一项技术并到处寻找它的应用场景，这种做法很诱人。我干过，大家都干过。但那些创造最大价值的工程师是逆向工作的：他们痴迷于深度理解用户的问题，让解决方案从这种理解中自然浮现。 “用户痴迷”意味着花时间处理客服工单，与用户交谈，观察用户在使用中的挣扎，不断追问“为什么”，直到触及问题的本质。真正理解问题的工程师往往会发现，优雅的解决方案比任何人预期的都要简单。 而那些从解决方案出发的工程师，往往为了证明方案的合理性而制造复杂性。 2. 单纯的“正确”很廉价，共同达成“正确”才是真本事。 你可能赢了每一次技术争论，却输掉了整个项目。我见过才华横溢的工程师因为总是做房间里最聪明的人而招致沉默的怨恨。这种代价日后会以“神秘的执行问题”和“奇怪的阻力”显现出来。 关键技能不在于你是对的，而在于进入讨论以对齐问题，给他人留出空间，并对自己确信的事情保持怀疑。 观点鲜明，但心态开放（Strong opinions, weakly held）——这并非因为你缺乏信念，而是因为在不确定性下做出的决策不应与个人身份绑定。 3. 行动至上。发布产品。你可以修改糟糕的页面，但无法修改空白的页面。 追求完美会导致瘫痪。我见过工程师花了数周时间争论他们从未构建过的东西的理想架构。完美的解决方案很少来自纯粹的思考——它来自与现实的碰撞。人工智能在很多方面对此都有帮助。 先做出来，再做对，最后做更好。把丑陋的原型放到用户面前。写下设计文档那凌乱的初稿。发布那个让你感到有点尴尬的 MVP（最小可行性产品）。你从一周的真实反馈中学到的东西，比一个月的理论辩论还要多。 动能创造清晰度。分析瘫痪一无所获。 4. 清晰度代表资历。炫技是累赘。 写出“聪明”代码的本能在工程师中几乎是普遍存在的。这感觉像是能力的证明。 但软件工程是当你加上“时间”和“其他程序员”这两个变量后发生的事情。在那种环境下，清晰不是一种风格偏好——它是降低运维风险的手段。 你的代码是写给那些在凌晨 2 点故障期间维护它的陌生人的战略备忘录。请优化他们的理解成本，而不是你的优雅程度。我最尊敬的资深工程师都学会了永远用清晰去交换炫技。 5. 新奇技术是一笔贷款，你将用故障、招聘难度和认知负担来偿还。 把你对技术的选择看作是一个只有少量“创新筹码”预算的组织。每当你采用某种非标准技术时，就花掉一个筹码。你负担不起太多。 重点不是“永远不要创新”，而是“只在你能获得独特回报的地方创新”。其他一切都应默认为无聊的技术，因为无聊的技术有已知的故障模式。 “最适合工作的工具”往往是“在许多工作中表现最不坏的工具”——因为维护一个像动物园样复杂的环境才是真正的重税。 6. 代码不会为你代言，人会。 在职业生涯早期，我相信优秀的作品会为自己说话。我错了。代码只是静静地躺在仓库里。你的经理要在会议上提及你，或者不提及。同事会推荐你参与项目，或者推荐别人。 在大型组织中，决策是在你没被邀请的会议上做出的，使用的是你没写的摘要，由那些只有五分钟时间和十二个优先事项的人决定的。如果当你不在场时没有人能阐述你的影响力，那么你的影响力实际上就是可有可无的。 这不仅是关于自我推销。这是为了让价值链对每个人——包括你自己——都清晰可见。 7. 最好的代码是你没写的代码。 我们在工程文化中推崇创造。没人会因为删代码而升职，尽管删除往往比增加更能改善系统。你没写的每一行代码，都是你永远不需要调试、维护或解释的一行。 在构建之前，先穷尽这个问题：“私如果我们干脆……不做会怎样？”有时答案是“没什么坏处”，那就是你的解决方案。 问题不在于工程师不会写代码或不会用 AI 写代码。问题在于我们太擅长写代码，以至于忘记了问自己是否应该写。 8. 规模化之后，即便是你的 Bug 也有用户依赖。 当用户足够多时，每一个可观察到的行为都会变成依赖项——不管你是怎么承诺的。有人在抓取你的 API，自动化你的怪癖，缓存你的 Bug。 这产生了一个职业层面的洞察：你不能把兼容性工作视为“维…

AI 多代理大规模编程的尝试
type: item
date: 2026-01-19T10:49:23+08:00
description: AI 多代理大规模编程的尝试 背景 最近 cursor CEO 整了一个大活。用 Cursor 库构建了一个基于 GPT-5.2 的浏览器，包含超过 300 万行代码。 这个浏览器的表现为如下： 思考 数周能达到这个完成度，很不错。从一个demo角度是可以的。但是，从软件维护角度，这么大的产品后续迭代会是个灾难。 AI可以理解为一个无所不知的初级程序员，对于简单的项目，一次prompt就可以完成实现。但是对于大规模的软件开发，依旧不会是银弹。目前这个浏览器项目就是一个示例。 程序员可以利用AI提高自己的生产力。让软件产品更快、更好输出。 反过来，让AI规划产品，规划软件设计，目前来看不是一个好主意。 参考 原始推文 AI 生成的 chrome，wilsonzlin/fastrender cursor scaling agents

远程执行python脚本
type: item
date: 2026-01-14T16:39:31+08:00
description: 远程执行python脚本 uv 远程执行脚本介绍 Running scripts | uv Python scripts can be run directly from their URLs using uv run. 很多零碎的小脚本，可以放在云上，可以方便远程执行。 claude-code-transcripts_rename_html_with_prefix uv run https://guacamole.961118.xyz/my-oss-storage/2026/01/claude-code-transcripts_rename_html_with_prefix.py 适用场景： --------- - 有一组相互链接的 HTML 文件（如 index.html, page-001.html, page-002.html...） - 想给这些文件统一加前缀（如 kline-index.html, kline-page-001.html...） - 需要同时更新文件内部的所有链接，避免跳转失效

嵌入式软件分层
type: item
date: 2026-01-14T15:46:50+08:00
description: 嵌入式软件分层 软件分层的核心目的是降低开发者的心智负担。当我们面对一个复杂系统时，不需要同时思考从硬件寄存器到业务逻辑的所有细节，而是聚焦于当前层的职责，信任下层提供的抽象。 分层带来的价值： 可替换性：更换硬件平台时，只需修改驱动层 可复用性：协议层代码可以在不同项目间复用 可测试性：每层可以独立进行单元测试 协作开发：不同开发者可以并行开发不同层 常见的软件分层 AUTOSAR AUTOSAR（汽车开放系统架构）是汽车电子领域的工业标准，提供了完整的分层规范： ┌────────────────────────────────────┐ │ Application Layer (SWC) │ 应用软件组件 ├────────────────────────────────────┤ │ Runtime Environment (RTE) │ 运行时环境 ├────────────────────────────────────┤ │ Services Layer (BSW) │ 基础软件服务层 ├────────────────────────────────────┤ │ ECU Abstraction Layer │ ECU 抽象层 ├────────────────────────────────────┤ │ MCAL │ 微控制器抽象层 ├────────────────────────────────────┤ │ Hardware │ 硬件 └────────────────────────────────────┘ AUTOSAR 的优势在于标准化程度高，有完整的规范文档和工具链支持。但对于中小型嵌入式项目来说过于复杂。 OSI 七层模型 OSI 模型是网络通信的经典参照，专注于数据在网络中的传输： ┌──────────────────┐ │ 应用层 │ HTTP, FTP, MQTT ├──────────────────┤ │ 表示层 │ 数据格式转换、加密 ├──────────────────┤ │ 会话层 │ 连接管理 ├──────────────────┤ │ 传输层 │ TCP, UDP ├──────────────────┤ │ 网络层 │ IP 路由 ├──────────────────┤ │ 数据链路层 │ 帧封装、MAC ├──────────────────┤ │ 物理层 │ 比特流传输 └──────────────────┘ OSI 模型的价值在于清晰定义了每层的职责边界，但它只覆盖"通信"这一个维度，不涉及业务逻辑和系统服务。 面向业务数据流的六层模型 结合 AUTOSAR 的分层思想和 OSI 的通信模型，针对中小型嵌入式项目提出简化的六层架构。核心关注点是业务数据如何从硬件一层层流向应用。 分层 ┌─────────────────────────────────────────────────────────────────┐ │ L6 应用层 │ 状态机 │ 业务逻辑 │ UI 交互 │ ├─────────────────────────────────────────────────────────────────┤ │ L5 服务层 │ 日志 │ 配置存储 │ 定时任务 │ Shell │ ├─────────────────────────────────────────────────────────────────┤ │ L4 协议层 │ Modbus │ 私有协议 │ Protobuf │ JSON │ ├─────────────────────────────────────────────────────────────────┤ │ L3 传输层 │ TCP/UDP │ 可靠传输 │ 分包重组 │ ├─────────────────────────────────────────────────────────────────┤ │ L2 链路层 │ UART帧 │ CAN帧 │ 以太网帧 │ ├─────────────────────────────────────────────────────────────────┤ │ L1 驱动层 │ HAL │ 外设驱动 │ DMA │ 中断 │ └─────────────────────────────────────────────────────────────────┘ 各层详解 L1 驱动层 (Driver/HAL) 职责：屏蔽硬件差异，提供统一的外设操作接口 向上提供：字节级别的读写能力 经典参照： 项目 特点 STM32 HAL ST 官方库，接口统一，易于移植 CMSI…

web 串口助手
type: item
date: 2026-01-12T16:53:33+08:00
description: web 串口助手 想自己做一个web 串口助手。之前在浏览 阮一峰周刊 的时候，有见到过一个惊艳的 web 串口助手，一直找不到，颇为遗憾。 今天下午，寻找了几个小时的github，发现开源的 web 串口助手 都是功能少了一点，与自己理想的差了一点。 最后终于找到了 云之彼端串口助手 在 阮一峰老师科技爱好者周刊「工具」和「资源」汇总 中找到的。

如何优雅的屏蔽GCC编译器告警
type: item
date: 2026-01-09T18:31:40+08:00
description: 如何优雅的屏蔽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 = …

GitHub Pages 与 Cloudflare Pages：写博客和部署网站的最佳平台
type: item
date: 2026-01-09T11:34:17+08:00
description: GitHub Pages 与 Cloudflare Pages：写博客和部署网站的最佳平台 写博客是开发者提升个人影响力的常见方式。大多数技术博客采用 Markdown 格式撰写——一种简洁实用的标记语言，摒弃了 XML、HTML 等复杂标记，让作者专注于内容本身。 部署博客也应如此：摒弃繁杂的配置，专注内容展示，让 Web 回归交流沟通的本质。 传统上，博客部署首选 WordPress，搜索引擎一搜便是。WordPress 软件本身是免费开源的，但自建需要购买服务器/主机，这对刚入门的开发者（尤其是学生）来说是一道门槛。本博客使用的是更轻量的 Typecho，同样需要服务器支持。 而 GitHub Pages 提供了另一种选择：完全免费、部署简单、撰写方便，非常值得推荐。 GitHub Pages Jekyll Jekyll 是一款静态网站生成器，能将 Markdown 文件转换为 HTML 网页，在这方面表现出色。 选择 Jekyll 并非因为我偏爱 Ruby，也不是认为它是最好的静态网站生成器。原因很简单：GitHub 原生支持 Jekyll，在 GitHub Pages 上部署 Jekyll 网站几乎零配置。 部署 只需将文章推送到 GitHub 仓库，即可触发自动构建和发布。GitHub Pages 还支持自定义域名，配置非常简单，你可以用自己的域名访问博客。 编辑 GitHub 本身就是一个强大的在线编辑平台。在任意 GitHub 仓库页面按下 . 键，即可在浏览器中打开 VS Code（github.dev），获得完整的编辑体验。这意味着你甚至不需要电脑，用 iPad 等移动设备也能随时写博客。 使用熟悉的编辑器是提高写作效率的关键。相比其他博客平台需要适应新的编辑界面，GitHub 的方式对开发者更加友好。 Cloudflare Pages Cloudflare Pages 不仅是静态网站托管平台，还具备一定的后端能力。GitHub Pages 能做的，Cloudflare Pages 基本都能做到，而且它与 GitHub 仓库无缝集成，保留了完整的在线编辑体验。 更进一步，结合 Cloudflare Workers 生态（如 KV Storage、R2 Object Storage、Durable Objects），可以实现轻量级的动态功能。这让你能够突破纯静态内容的限制，发挥创意，让网站更加丰富多彩。 同样地，Cloudflare Pages 也是免费的。 参考 https://burkeholland.github.io/posts/gh-pages-best-blog/

大模型的训练速度正在加快
type: item
date: 2026-01-08T18:34:52+08:00
description: 大模型的训练速度正在加快 DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning 是 DeepSeek 2026 年发布最新论文，里面讲述了可以通过纯强化学习（pure RL）来激发 LLM 的推理能力，而不需要人工标注的推理轨迹。 [...]