洛小山

@luoxiaoshan_ai · 2026-08-23

你大概也试过让 AI 帮你读源码。 仓库扔进去，然后过一会给你整一个 md。 看起来好像挺不错的，但要是真的去翻源码，经常找不到它说的那段，满满的幻觉。 我之前精读 Claude Code 和 OpenClaw 的时候，把这件事整理成了一套流程，把开源的代码库做成一本简单易读的书。 后来也用这套方法做了小山学堂等等。 现在三章样张和整套工具都开源了，如果你正好也有这个需要，欢迎体验一下。 https://github.com/itshen/source-reading-methodology

ahhhhfs

@abskoop · 2026-08-23

Vercel 开了一门完整的课程：Build Your Own AI Coding Agent Harness 教你从零手写一个完整、能真正干活的 AI 编码 Agent 框架

MateMatt

@mate_mattt · 2026-08-25

经过长达 7 个半小时的睡眠后，我想出一个个人在团队里 AI Coding 协作的方案： 1、团队每个人独立于原始代码仓库新开一个仓库，专门放自己的文档，prd，issues，tickets。 2、做一个专属个人开发的 skill，开头就写上，只看当前仓库的代码，忽略工作空间内的文档，专有文档链接是：例如 https://github.com/aaa/docs/.... 3、过程中如果需要记录文档也请将文档统一整理到刚才的仓库。 这样的好处: a> 对 AI 来说减少不必要的文档上下文压力，AI 读了代码，可以完全不读文档；除非是那些代码还没同步的新的开发计划或者方向调整，也就是你的个人任务。 b> 多人合作，每个人有自己的节奏和文档管理，即使仓库历史文档很乱，Agent 完全忽略。 c> 个人的 task 可以和自己的 issues 绑定，避免单一仓库多人合作时，issues 和 subissues 混乱。也无需强制每个人使用什么 skill 或者 AI 协作的方式。 d> 责任明确，Review 谁的模块，开谁的个人文档记录仓库，你甚至可以将个人的提示词定期同步到自己的独立仓库。避免多人多轮 AI Coding 后，分不清是谁 push 的 (尽管有 git blame，人多了管理也是难事)。 d> 你完全可以基于自己的个人仓库搞 loop engineering \ graph engineering。 今天睡醒后想到的，准备自己先实施一段时间，试试效果。

meng shao

@shao__meng · 2026-08-27

对抗 AI 设计 Slop：来自前 Figma 工程师的七条方法论 1. 始终着眼整体 设计过程本质上是三步循环（源自 Christopher Alexander「形式综合论」）： 1. 列出所有设计约束； 2. 构思满足约束的多种方案； 3. 若发现约束需增删，回到第一步重新整体推演。 关键警告：最常见的错误是跳过第 3 步，陷入"打地鼠式设计"——用户一反馈困惑就立即局部修补。AI 加剧了这种倾向（"把 X 做得更显眼""给 Y 加个入口"式的提示词），最终产出随机取舍、彼此割裂的拼布式界面。 正确做法：收到反馈先判断它是否改变了设计约束，再谈方案。作者团队用一份"小痛点文档"积累次要问题，待重设计时统一、连贯地解决，避免过度反应。 2. 做减法 Agent 天生爱"加东西"——多余文案、分割线、图标，正如它在代码里爱加冗余 try-catch、重复实现工具函数。产出的设计"比工程师手画的好看，但其实挺糟"。对策很简单：逐个元素追问"我真的需要它吗？" 3. 在设计工具里迭代 不要在真实产品代码里迭代设计。"原型引力"是隐形杀手：一旦 Agent 在代码库里搭出第一版，人就会倾向于在其上修修补补，而不再探索其他可能；且代码库上下文会迫使 Agent 生成与现有实现强行嫁接的方案。应使用 Figma（作者眼中仍是最佳，AI 集成日益增强）、Cursor Design Mode、Claude Design 或 HTML 原型等专用工具，并让 AI 为每个方案生成 3–4 个变体。 4. 使用组件与组件库 视图与逻辑分离、构建可复用组件——对工程师显而易见但极其重要，可避免"按钮被反复重实现"的视觉拼布。作者团队的实践：维护一个 /showcase 页面，让 Agent 先在此构建和调试 UI 组件，再接入主应用。 5. 使用预览部署 评估设计的最佳方式是真实数据。即使 Agent 完全按指令实现，拿到真实数据上手后仍可能发现不对——打磨和返工不可避免。对涉及前后端的大功能，作者团队将前后端拆成独立 PR：后端靠单元/集成测试验证，前端靠预览部署链接供人工验证。 6. 学会"偷" 绝大多数 UX 问题早已被人解决，正确的做法是取各家之长重新组合。优秀设计师开案第一件事都是收集大量竞品截图——工程师也应如此，这些截图还是喂给 Agent 的绝佳上下文。 7. 磨练品味 品味即对自身体验的反思能力，是创造而非制造 slop 的必要条件。产品工程师擅长识别"设计不对"，却缺乏修复它的"方案库"——这只能靠反复尝试与反思来积累。过程有趣但也残酷：在"够好"之前要承受密集的批评。作者团队没有全职设计师，采用"打谷式"方法：把设计扔到中间，团队一起"拿棍子敲打"直到满意。 AI 能加速设计的执行，但设计的判断力仍在人：用约束驱动整体思考、对 AI 的"加法冲动"做减法、在专用工具中探索多方案、以组件化和预览部署保证质量、借鉴成熟方案，并以持续反思培养品味——这才是工程师借助 AI 产出好设计的完整闭环。

Ren

@Ryrenz · 2026-08-22

🧠 浙大开源了一本《大模型基础》，六章全本 PDF 免费下 GitHub 上 1.65 万 stars 想系统补大模型的底子，中文材料一直不太够。要么是博客拼凑的碎片，读完不成体系；要么直接啃英文论文，术语和数学一起上，第一章就劝退。 这本《大模型基础》是浙大团队做的，六章顺着能力递进铺：语言模型基础、大语言模型架构、Prompt 工程、参数高效微调、模型编辑、检索增强生成。完整版 PDF 和分章节 PDF 都给了，每章还配一份相关论文列表，想往深了挖有现成的路。 有个挺有意思的设计：每章各用一种动物作为讲技术的示例背景，抽象概念套在具体形象上，读起来不那么硬。内容按月更新，作者团队还计划补上大模型推理加速和大模型智能体两块。同一个仓库里另外开源了一个多智能体开发框架 Agent-Kernel。 母语材料的价值不在于省翻译时间，在于你能把注意力全放在内容上。 GitHub：https://github.com/ZJU-LLMs/Foundations-of-LLMs

关木

@ZeroZ_JQ · 2026-08-26

我现在做业务型和网关型项目，基本都会优先用 Go。 所以看到 JetBrains 开源的 go-modern-guidelines 赶紧收藏、保存了 AI 编程正在出现一个新的软件层。 它会读取项目的 Go 版本，再告诉 AI： 哪些新语法可以用 哪些标准库已经更新 什么写法更符合现在的 Go 习惯 https://github.com/JetBrains/go-modern-guidelines

Charles在路上

@Charles77xixi · 2026-08-27

我觉得阮一峰老师的这篇写的就很不错 ，再补几点我自己的看法 1.交付粒度变了：未来一定会更强调端到端，程序员对结果负责，中高级程序员需要能够一个人cover：前后端测试部署运维 2.古德哈特定律：一定有很多东西是没办法自动化的，比如代码cr，实际上代码层面的review已经很晚了，像是计划以及需求架构层改动的review是一定需要人来做的 3.目前个人效率的瓶颈：已经最大的瓶颈不是 Coding，而是人脑的 Review Queue

yibie

@yibie · 2026-08-25

Total TypeScript 创始人 Matt Pocock 给编码 agent 写了一个解决 git 合并冲突的技能：解决前先把每一方追回各自的 commit 和 PR，在两个意图之间做选择，然后跑完项目自己的检查才提交。它从不允许 --abort。 《/resolving-merge-conflicts 技能》 面向真实工程师的 AI 技能 · 4 分钟读完 逐个冲突块，完成一次 merge 或 rebase。 Matt Pocock 安装这个技能 npx skills@latest add mattpocock/skills --skill=resolving-merge-conflicts 然后在你的编码 agent 里输入 /resolving-merge-conflicts 来源：mattpocock/skills（GitHub） 它做什么 resolving-merge-conflicts 逐个冲突块处理一个进行中的 git merge 或 rebase，然后运行项目自己的检查，最后以一次提交收尾整个操作。 它拒绝把冲突当成文本问题。在碰任何一个冲突块之前，它先把每一方追溯回它的主要来源（primary source）——commit message、PR、最初的 issue——所以它是在两个意图之间做选择，而不是在两段文本之间做选择；只要双方兼容，就两边都保留。真正不兼容的地方，它选与 merge 声明目标一致的那一方，并点名这个取舍。它不会发明新行为来掩盖冲突，--abort 不在它的选项里：merge 一定会被推进到一个完整的提交。 什么时候用它 输入 /resolving-merge-conflicts，或者在任务匹配时由 agent 自动调用。 当 git 已经停在它自己解决不了的冲突上时用它。它的作用域就是你面前这个冲突，两边之外的东西一概不管： • 正在 merge 或 rebase 中途，工作树里有冲突标记 → 用这个技能 • merge 已完成，某样东西开始行为异常、原因不明 → 用 diagnosing-bugs • 正在规划怎么切分工作、让分支少碰撞 → 都不用：看下面"并行工作"那个问题 主要来源优先于 ours 和 theirs 这个技能要杀死的失败模式是按旗标解决：--ours、--theirs，或者手工删掉看起来不那么重要的那块，让冲突标记消失、构建能编译。这种解决方式可能在语法上完美，却仍然悄悄丢掉某个人故意做的修改。 你没读过的东西，你不可能保留它的意图。所以工作从历史开始（commits、PRs、tickets），然后才轮到 diff。循环里还有一步是出于同样的原因：技能会找到仓库自己的自动化检查，在提交之前运行它们——因为 merge 是 git 里最容易产出"两边分支都满足、但哪边的测试都过不了"的代码的地方。 常见问题 Claude Code 自己解决冲突已经解决得不错了。为什么还需要一个技能？ 增量价值在于"找主要来源"和"跑反馈循环"这两步，否则每一步都得手动提示。一个没被提示的 agent 通常只会从 diff 里得出一个说得通的解决，然后就停在那里。这个技能的价值，是它不允许 agent 跳过的两步：读懂每一方为什么存在，以及之后跑检查。相比一个好的模型，这只是薄薄一层余量，而且它有意如此：至少有一位读者预测过，这个完整的技能会在模型变好后变成空操作。 要不要让并行 agent 避开同一个文件，从源头上避免冲突？ 大多不需要。在并行任务之间分文件划地盘，省下的不如花掉的多——因为 agent 处理 merge 冲突已经足够好，这个权衡没有看上去那么惨烈。唯一值得保留的纪律是先做大重构。一个大 rename 在十个分支分叉出去之后才落地，那才是永远贵的情况。 一个来自并行 worktree 用户报告的提醒：当多个兄弟会话各自在自己的树里完成一个 ticket，合并回来最好由写那个改动的会话来做——因为它已经知道意图。最后把所有人的冲突堆给一个 agent 处理，恰恰丢掉了本技能第 2 步必须重新构建的那个上下文。 为什么永远不用 --abort？ 中止会丢掉已完成的解决工作，下次再试时你还会面对同一个冲突，原封不动。这个技能就是为"merge 一定会发生"的场景写的。如果你已经决定它不该发生，那是在调用之前就该做的决定，而不是循环里的一个分支。 它工作正常的标志 • agent 在解决过程中把 commit message、PR 或 issue 引用给你看，而不只是 diff 块。 • 每个冲突块最后要么两边行为都在，要么带着一条明确注明"丢掉了什么、为什么"的记录。 • 结果里没有出现在任何一边分支上的东西。 • typecheck、测试和格式化是在提交之前被找到并跑绿的，而不是等你发现坏了之后。 • 你结束时工作树干净、操作已完成，多 commit 的 rebase 里剩下的每个 commit 都处理完了。 它在哪里 一个随时可调用的独立技能，不依赖任何其他技能：git 卡住时它开始，工作树干净并提交后它结束。它唯一的近邻是 diagnosing-bugs——在 merge 干净解决、但合并后的代码行为异常时接手：那已经是诊断问题，不是冲突问题。它完全在"从想法到上线"的主流程之外，ask-matt 才是说明它前后该跑什么的地图。 原文：https://www.aihero.dev/skills-resolving-merge-conflicts #编码Agent #Git #AI技能

yuya

@isamisushi_y · 2026-08-24

git worktree作ると.envとかローカル設定が消えてめんどくさい問題、.worktreeincludeで解決する。 .gitignoreと同じ構文で「持っていきたいファイル」を書くだけ。 Claude CodeもCodexも両方対応してる。 .env .env.local config/secrets.json これ置くだけでworktree作成時に自動コピーされる。地味だけど並列作業の摩擦がかなり減る。

小墨同学

@xiaomovps · 2026-08-25

Pi 处理上下文压缩的方式，比我想象中有意思！ 先简单说一下，Pi 原生的上下文压缩逻辑，其实非常简单： Context 快满了 → 总结旧上下文 → 保留最近消息 → 继续工作。 但是社区已经出现了好几种不同的思路： 1. pai-acp：遗忘流派，让 AI 自己决定忘掉什么 不再是等 Context 满了再统一压缩，而是让 Agent 主动去判断哪些历史已经没价值，然后提前压掉；需要时还能搜索甚至恢复。 2. pi-smart-compact：它会重点保留当前目标、修改过的文件、错误、关键决策、未完成事项，更像是一个留给自己的备忘录。 3. pi-context：把上下文当成 Git 管，可以主动 checkpoint、查看 timeline，再选择性 compact。 4. Hypa：设计思路是，最好的压缩，是就是从一开始就不让垃圾进入上下文，这样比单纯的上下文到达上限之后在压缩更省token。 5. pi-press：把压缩流程前置，上下文接近阈值时就提前生成摘要，真正需要 Compact 时可以直接切换，减少 Agent 因压缩产生的停顿。 其实看了这么多插件的设计思路，总结下来就是在合适的实际完成合适的内容选择，可能一开始就不让垃圾数据进入上下文是对的。 也有可能是提前就完成压缩操作，对你来说无感知才是最舒服的，但是需要解决的还是一个最根本的问题，Agent记忆 到底是怎么样的。 现在还没有一个盖棺定论的结论，但是这些启发和思路都是一直都在的。

Chasen

@chasen_liao · 2026-08-27

你的 pi 正在用 grep 往 Context 里塞垃圾，我实测了一下午终于换掉了... pi 内置的 grep 其实就是 rg --json 套壳，limit 100 + 截断 50KB + 默认带 --hidden，搜一次 TODO 这种高频词，直接30 多条平铺甩进上下文。Token 烧了，关键文件还被埋在后面 这个问题 Codex 早就用优化过的 rg 解决，pi 这边最干净的解法我测下来是 @ff-labs/pi-fff 它不是再包一层 rg，而是把 FFF 这个 Rust 原生库直接接到 pi 里，不起子进程，文件在后台预索引。核心变化就三点：frecency 排序常用文件自动置顶、git-aware 改动过的文件加权、grep 结果分组 + cursor 分页 我测了一下，本地建了个小项目 src/app.ts / utils.ts / README.md，往 noise.ts 里塞了 30 行 TODO fix，总共 33 个命中 用内置逻辑等价于 rg "TODO"，33 行平铺一次性返回。换成 ffgrep： 第一页只给 20 条，全是 noise.ts 分组好的 1-20，还带一句 [Continue with cursor="fff_c1"]。第二页 ffgrep cursor="fff_c1" 才吐剩下 13 条，app.ts 和 utils.ts 被分在后面，首屏完全不淹没 fffind 也一样，fffind pattern:"app" 直接模糊命中 src/app.ts 和 README.md，frecency 会把你最近改过的文件排前面，不用写 glob。 1️⃣ 安装就一行，不用装 rg/fd 二进制 > pi install npm:@ff-labs/pi-fff 装完 reload 就有 ffgrep / fffind / fff-multi-grep。默认是 tools-and-ui 额外加工具，想直接替换掉内置 grep 就切 override 模式：PI_FFF_MODE=override 或启动加 --fff-mode override 2️⃣ 为什么选它不选别的 我扫了一遍 pi 插件库同期数据，@ff-labs/pi-fff 周下载 6,830 / 月 33,928，版本 0.10.5，已经 80+ 个 nightly 迭代，是搜索类最成熟的。对比 pi-lean-grep 周下载才 4，pi-hypa 是做压缩的，定位不一样。 3️⃣ 体感变化 默认 ffgrep limit 20 对比内置 100，首屏噪音直接砍掉 80%。配合 cursor，你是「精准定位再 read」，而不是「先把50KB 塞进 Context 再让模型自己找」。/fff-health 还能看索引和 frecency 状态 说真的，pi 默认 4 个工具 read,bash,edit,write 之外，grep/find 本来就得显式启用，既然要开，不如直接开这个 已经在用 pi 写代码、被 grep 刷屏搞崩过 Context 的人可以试试，尤其大仓、TODO / FIXME 满天飞的项目，提升最明显 推荐大家在pi里试试 传送门 👉 https://pi.dev/packages/@ff-labs/pi-fff #pi #VibeCoding

Chasen

@chasen_liao · 2026-08-28

我实测发现 。。。很多模型会默认调用 bash 命令，而不用 Pi 内置的 grep、find 指令，直接使用 ls、cat 这些命令行工具，应该是 模型没有针对 harness 调优过，所以很多默认会直接使用 bash，而直接使用这些会导致上下文膨胀的很厉害 bash 里的 grep 是上下文杀手。它不认识 .gitignore，递归一跑，node_modules 里每一行匹配都原样灌进 Context，token 哗哗地掉。内置搜索至少有 limit、分页和排序，输出是可控的，但是模型会不喜欢用。。。 更有说服力的是，帮我把搜索纪律写进 AGENTS.md 的那个 agent，自己就在 bash 里跑了 grep 查 pi-fff 源码，被我当场抓包。惯性走 bash 不怪模型，是因为很多模型训练语料就是这样，没有专门为 Pi 调优过 所以我重新加强了全局规则，现在 AGENTS.md 的工具节就两行： 1️⃣搜索用 grep/find 内置工具，多 OR 词用一次 multi_grep，必须走 bash 时用 rg 2️⃣定位后用 read 的 offset/limit 只读命中附近，工作区外已知文件直接 read 为什么留 rg 这个口子呢？rg 默认尊重 .gitignore，跳过二进制和隐藏文件，真要用 bash 搜，输出经常比 grep 干净一个数量级 这样子你的上下文就干净了

Michael Guo

@Michaelzsguo · 2026-08-26

Lauren Tan @poteto 是 Cursor 的工程师，之前在 Meta 做 React Compiler，也在 Netflix 做过 tech lead 和工程经理。 她加入 Cursor 只有五个月。第一个月还在熟悉代码库，上个月已经合入了 1000 个 PR。这个月才过去 12 天，她又合入了接近 800 个。 这不是 AI slop code，而是你每天都在使用的 Cursor 的代码。 很多人，包括 Claude Code 的 Boris，都提过自己借助 coding agent 达到了类似的效率。但真正愿意把工作方法完整分享出来的人并不多。Lauren 在这个一小时的视频里，几乎是手把手讲了她怎么走到这一步。 她认为，用 AI coding 最大的问题不是生成代码，而是验证代码。 如果 agent 不能自己运行产品、操作界面、读取 CPU trace 和 heap snapshot、打开模拟器并复现问题，那么最后还是要由你来检查结果。你就是整个流程的 verifier，也是无法并行工作的瓶颈。 Lauren 的做法，是先给 agent 建立完整的验证能力：让它能通过 Chrome DevTools 或模拟器实际操作产品，再用 feature map 告诉它每个功能在哪里、怎么进入。这样即使同事只丢来一张截图，或者一句很模糊的 bug 描述，agent 也能找到对应功能，复现问题并验证修复。 每当她发现 agent 在猜测、漏读代码或走错方向，就把这个失败模式写成一条 skill。然后像测试代码一样测试这些 skill：让多个 sub-agent 分别执行任务，由 coordinator 制定 rubric，再让另一个模型交叉检查评分，反复迭代到结果足够稳定。 现在，她甚至允许 agent 自动合并 PR。有一天早上醒来，已经有 20 个 PR 自动进入 main；她直接在 main 上检查，结果都没有问题。 这套方法不是简单的提示词技巧，更像做工程管理：先设计好环境、流程和验收机制，再让团队并行工作。只不过这支团队，现在由几十个 coding agent 组成。 https://x.com/0xCodez/status/2091980766372639135/video/1

LanLance

@LanLance24 · 2026-08-26

各个大厂都在推进 AI-SDLC，而最近 Claude 推出了 AI-SDLC 的方法论手册。 Coding 已经不再是软件开发的主要瓶颈，瓶颈正在迁移到需求评审、功能验证、Code Review、反馈。 把整个 SDLC 重构成一个 Agent 可读、可执行、可验证、可审计的闭环系统，才是真正的 AI-Native，生成多少行代码并不重要。 几个关键点： > AI-SDLC 并发的上限不在于能开启多少个 Claude、Codex，在于一个人能 Review 几条并行流，因此未来 Harness 的竞争点也许会变成如何压缩人 Review 的成本。 > 产物即协议，Intent → Spec → Plan → Code → Eval → Deploy，每一步产物都是下一步的上下文和协议 > 把团队经验、约束、踩坑沉淀进 repo，而不是留在人的脑子 > Agent 必须能自己测试、观察结果、修复；没有可靠反馈，再强的模型也很容易跑偏 https://claude.com/blog/the-ai-native-sdlc-playbook

sunmer

@sunmer575399 · 2026-08-26

刚发现一个宝藏项目system-design-101，84.1k star，省了自己写AI工具的时间 1️⃣ 把复杂系统架构全画成一张张图解，缓存、消息队列、负载均衡这些概念，看一遍图就懂，不用去啃几百页的技术书 2️⃣ 每个知识点都配了真实场景拆解，比如抖音的推荐系统怎么扛住千万级并发，看完直接能套到自己的项目设计里 3️⃣ 还整理了面试高频题和答题框架，从"设计一个URL短链"到"分布式事务怎么做"，照着思路捋一遍，思路清晰多了 想折腾AI的自己去看看。 这套内容其实就是ByteByteGo那帮工程师的实战笔记开源出来的，平时他们给大厂做架构咨询，一小时收费几千刀那种 现在全免费放出来了，我刷了两天，感觉比花钱买的系统设计课还实在。 亲测，你们现在系统设计都怎么准备的，有更好的资源吗？ 🔗 https://github.com/ByteByteGoHq/system-design-101 #AI #AI工具老炮

打开这条 X 帖子

Chasen

@chasen_liao · 2026-08-27

https://x.com/i/article/2090655519673626624

Uber Engineering

@UberEng · 2026-08-29

https://x.com/i/article/2090828118454071296