跳到正文

全部动态

今日 0 条
5/8周四
4/30周三
4/17周四
4/10周四
  1. Harper Reed34

    Harper Reed:AI 编程让瀑布模型变成 15 分钟一轮

    Harper Reed 认为 AI 代码生成正把开发推向"15 分钟瀑布":先写清规格、让模型生成、再审查,并可同时跑多个智能体分别写功能、文档和测试。他建议团队先用低风险内部项目做小范围试点、轮换成员参与,并把规格和架构文档沉淀到共享仓库。他还提醒 AI 容易过度测试基础逻辑,需频繁提交以便回滚。

4/6周日
3/18周二
3/1周六
  1. Hacker News · AI Code Review 讨论42

    AI 代码审查工具为何没解决你的真问题:作者工具与审查者工具的错位

    Vibinex 创始人指出,团队采购 CodeRabbit、CodeAnt、Greptile、Ellipsis 等 AI 代码审查工具,主要优化的是作者写代码的质量,而非减少审查者逐行读代码的时间。审查者仍需自行理解改动、识别业务逻辑与架构影响,原有流程一步没少。作者工具与审查者工具应互补,而非互相替代。

1/13周一
  1. Harper Reed15

    Harper Reed 为个人网站新增媒体追踪板块,用 Claude、Aider 和 ChatGPT 自动收集阅读、音乐与书签数据

    Harper Reed 用 Claude、Aider 和 ChatGPT 为自己的网站新增了一个媒体板块,自动追踪并展示他在 Goodreads 上的已读书籍、Spotify 上最近保存的曲目,以及通过 feedbin/NetNewsWire 收藏的链接。数据由几个脚本抓取后存为 YAML 文件,再生成 Hugo 博客条目,并提供了全量、书籍、音乐、链接四个 RSS 订阅源。

12/19周四
12/5周四
4/21周日
  1. Jesse Vincent38

    让 LLM 起草我的 commit message

    Jesse Vincent 基于朋友 harper 的工具改造出一套 LLM 自动起草 commit message 的方案,调整了提示词、git hook 和模型 temperature,并向 LLM 提供完整文件上下文。他使用 gpt-4-turbo、temperature 0.02、seed 1,约 90% 的情况下仍需手动修改,但改动较小且 commit message 更详细。

4/12周五
1/19周五
  1. Jesse Vincent22

    KiCAD 8 用 kicad-cli 取代 500MB Docker 镜像生成制造文件

    KiCAD 8 首个 Release Candidate 发布后,作者用一段由 LLM 代写的 shell 脚本,通过 kicad-cli 一条命令导出 gerber、PDF 原理图、BOM、坐标文件、STEP 3D 模型和钻孔文件并打包成 zip。此前他为此维护过一个 500MB 的 Docker 镜像,靠无头 X server 模拟点击 GUI 才能生成原理图和 BOM。

11/29周三
8/26周六
8/25周五
  1. Ryan Lopopolo36

    做最简单可行的事:一位工程师谈如何用最小方案破解本地化项目设计僵局

    面对一个12名工程师参与、前5周未写一行代码的 Web 与移动端本地化项目,作者主张“做最简单可行的事”:只处理 happy path、尽量打桩、推迟行为定义。团队随后一周内用 react-i18next 和两个硬编码 JSON 文件,让 Web 与移动端设置页、登录页和仪表盘实现德语与英语切换,并以每周手动拉取翻译快照提 PR 的 toil 替代自动化流水线。

8/10周四
  1. Martin Fowler · Exploring Generative AI32

    编码助手无法取代结对编程

    Thoughtworks 的 Martin Fowler 撰文指出,GenAI 编码助手只能覆盖结对编程的一小部分收益,GitHub 将 Copilot 称为“你的 AI 结对程序员”是对结对实践的误导。结对编程还能带来集体代码所有权、代码库历史与隐性知识共享、改善团队流动与持续集成,并锻炼沟通、共情等协作能力,这些是大语言模型无法提供的。他建议用编码助手让结对更好,而非取代结对。

8/1周二
  1. Martin Fowler · Exploring Generative AI52

    行内代码补全什么时候更有用

    Martin Fowler 结合 Thoughtworks 内部使用 GitHub Copilot 的经验,分析行内代码生成在什么情况下更有用。他给出的有利条件包括技术栈更主流、问题更常见、生成片段更小、开发者更有经验、出错代价更低,并指出经验不足的开发者使用这类工具时任务耗时可能反而增加 7% 到 10%。他建议开发者花一段时间在安全区内外实验,逐步建立对工具适用边界的判断。

7/27周四
  1. Ryan Lopopolo26

    Ryan Lopopolo:如何通过让团队失败来扩展自己的管理半径

    Ryan Lopopolo 作为管理 5 个团队、35 名工程师的 Group Tech Lead,提出用"失败成本"判断哪些项目可以放手让团队自主试错,从而把每周注意力集中在最多 3 件不能失败的事情上。当团队在自主处理遗留基础设施时反复出现 SLA 违规,他转而通过结对写代码、引入可复制的代码模式和代码审查示范来补齐技能缺口。

  2. Martin Fowler · Exploring Generative AI38

    用三个 median 函数看 GitHub Copilot 辅助编码的能与不能

    Martin Fowler 用 GitHub Copilot 生成 TypeScript 的 median 函数,Copilot 给出三个实现:第一个会修改输入数组,第二个用 slice() 复制后正确,第三个因忽略偶数长度而错误。他还让 Copilot Chat 先生成测试,测试覆盖了奇偶长度、负数与重复值,并让 ChatGPT 指出第三个实现的问题。

6/14周三
  1. Ryan Lopopolo15

    Rust RFC 的反馈窗口:为什么提案不该对所有人在所有阶段开放

    Rust 项目成员在讨论一个有争议的 RFC 时提出,并非所有提案在其生命周期每个阶段都对所有相关方开放反馈。作者由此总结出反馈窗口的实践:用类似根回的方式先建立共识,文档和设计未成熟前不广泛分享,明确反馈截止时间和期望的反馈类型,决策后明确“锁定”并做到 disagree and commit。作者认为,在反馈窗口之外提意见往往收效不佳并引发摩擦。

6/13周二
9/19周日
12/24周四
7/15周一
3/3周日
  1. Ryan Lopopolo31

    Stripe 资深工程师如何用 nemawashi 构建共识

    Stripe 工程师 Ryan Lopopolo 分享用 nemawashi(缓慢、审慎的共识构建)推动变革的经验:他通过跨基础设施团队的一对一沟通,最终以四行 PR 移除了 AWS 对 EBS 实例类型的限制。这一改动两年后带来 API 性能提升、构建加速、集群效率提高和边缘网络容量增加等连锁效果。

1/27周日
  1. Ryan Lopopolo17

    用 Rust 构建 Punchtop 的学习反思

    作者用约 3700 行 Rust 和 JavaScript 重新实现了音频游戏 Punchtop,这是他首次正式上手 Rust。他认为掌握内存模型后 Rust 用起来很顺手,开发中仅出现两次 panic,并特别称赞 Clippy 帮助写出更地道、更高效的代码,以及内联测试和 doc tests 带来的便利。

12/28周五
11/16周五
11/5周一
10/27周六
  1. Ryan Lopopolo12

    Stripe 云成本核算团队如何与财务团队高效协作

    Stripe 云成本核算团队通过与财务团队建立共享数据、双周 DRI 同步和统一核算口径,显著降低了 AWS 成本。双方统一以公开按需价格衡量 AWS 支出、按 xlarge 归一化单位讨论实例用量,并将 EC2 预留实例覆盖率目标提高 10%,同时开始购买 ElastiCache 预留实例。工程侧还构建了自动对账系统,将月度 AWS 发票与成本和使用报告核对。

  2. Ryan Lopopolo22

    AWS 基础设施就是你的组织架构图

    AWS 资源分布能反映组织的技术决策方式:57 个 RDS 实例配置各异说明技术决策分散,EC2 仅六种实例类型则说明容量规划集中管理。作者认为应针对 Elasticsearch、成本优化、跨团队规划等关键领域各指定一名 DRI,Stripe 已采用该模式。