我不读代码，所以我在学 GitHub

AI 以一种我未曾预料的方式改变了 GitHub。这个我过去视作工程领地的地方，正在成为软件工作如何变为现实的蓝图。我依然不读代码，但我希望理解围绕代码的工作。

很长一段时间里，GitHub 游离在我日常操作界面的边缘。我知道它很重要，当陈旧的 Issue 或评论里藏着我要的线索时，我会用到它，但我很少把它看作一个能让自己的判断力留存的地方。我的优势来自客户、产品决策、定位、搜索，以及那种在看到问题之前就能感觉不对劲的能力。

这在我构建软件公司的几十年里一直如此。我能和工程师沟通，理解权衡，推动产品决策，帮助团队更贴近真实的客户问题。读懂代码从来不是我的手艺，我也从未假装是。

我上一次真正写代码，还是小时候在 Radio Shack，试图让展示用的电脑出故障。我用 QBasic 写循环，店员只能通过重置机器或关闭电源来停止。后来我浅尝过 Ruby on Rails，但学到的主要是自己还有多少不懂。这让我对工作本身有了同理心，也让我不再幻想自己精通。

这个周五，我会做一场直播，讨论 GitHub 对于如今用 AI 建设的人来说意味着什么。在 hiten.com 注册即可参与。

曾经的 GitHub 是证据，而非环境

多年来，我最有用的技术贡献是找到线索。我曾比工程师更擅长 Google，这听起来比当时的感受更有趣。当团队卡住时，问题往往被冠以错误的名称。每个人都在搜索错误信息、框架术语或我们产品用的说法，而答案藏在某个更古老、更奇怪的措辞下。

第一次搜索通常失败，因为第一次搜索太字面。更好的路径是围绕问题移动，直到合适的语言浮现。有时，线索藏在 Stack Overflow 的回答里。有时，它出现在某个 GitHub Issue 的评论中，来自已经碰到同一堵墙的人。还有些时候，一条发布说明解释了行为，却从未描述我们的确切情况。

搜索从来不只是打字。它是一种在模糊中停留，直到问题揭示出它应该被叫做什么的方式。

这很重要，因为软件被半可见的知识包围着。客户投诉很少以清晰的需求形式出现。支持对话可能在有人知道如何命名之前就揭示了真实问题。Bug 报告可能包含太多噪音，却有一个能改变诊断的细节。销售异议可能在路线图有语言描述之前就指向了产品缺口。

GitHub 是我搜索表面的一部分。我会通过 Google 到达那里，读足够的内容提取线索，然后把线索带回对话中。GitHub 更多是证据，而非环境。

AI 正在改变这一点。

判断力正在向工作本身靠近

人们总是把 AI 编码简化为生成代码的能力。这低估了正在发生的事情。

更有趣的变化是，判断力可以更早进入工作流程，并在更多的交接中存活。一个混乱的想法可以变成计划，计划变成智能体任务，最终变成拉取请求。修正可以作为可复用的技能被捕获。即便是截图、转录文字、Bug 报告或客户投诉，也能以更少的转译进入工作。

这改变了那些理解客户和产品却不生活在代码中的人的角色。创始人可以用普通语言解释客户痛点，并看到它反映在计划中。产品经理可以在实现开始前定义产品需要的行为。支持团队可以将重复的升级模式转化为可测试的案例。营销人员可以识别语言在技术上正确却仍错过买家真正关心之处的时刻。

这些输入过去通过会议、文档、Slack 线程、审查评论和记忆传递。一部分幸存下来，很多被软化或丢失。AI 为这些判断力提供了一条通向工件的更短路径。

工作仍然需要在压力下的品味。有人必须知道什么应该存在，为什么重要，哪种行为算成功，风险藏在哪里，以及哪种答案会在演示之后依然有效。

模型可以生成代码。工作仍然需要有人能识别结果是否值得存在。

Matt Van Horn 展现了循环的形状

Matt Van Horn 是我反复想到的人，因为他让这个转变无法被忽视。他说自己不读代码，然后展示工作：计划、智能体、GitHub、开源、发布、反馈，再来一遍。

重要的是他围绕自身限制构建的循环。

他的工作从代码之前开始。想法变成计划，计划在执行前收集上下文。仓库模式、过往决策、外部研究、验收标准、完成的定义——统统被拉进来。计划成为第一个重要的工件。

这很重要，因为计划为智能体提供了遵循的路径，也为人提供了施压的对象。测试工作是否瞄准了正确的问题变得更容易。你可以注意到客户语言何时出错，识别出风险假设在哪里，发现薄弱的例子或被误解的工作流程。

这些都不需要读每一行代码。它需要判断力。

Peter Yang@petergyang·6月14日
“我不是工程师，但不知怎的我能交付有价值的东西，这既疯狂又奇怪，仍然让我震惊。”
这是我与@mvanhorn 的新一期节目，一位没有技术背景的创始人，却贡献了 100+ 开源项目，并在 GitHub 上获得了 44K+ 星，尽管他不会……
显示更多
254 332 484K

智能体可以创建计划、写代码、快速生成多个版本，但它们无法可靠地判断哪个版本真正值得发布。这个责任仍然在人身上。人提供信号。

人决定工作是否解决了正确的问题，是否准确反映客户上下文，是否考虑了关键风险，最终是否推进了产品。智能体扩展了可以尝试的工作量，而人的判断决定了什么能存活。

这就是为什么随着 AI 变好，信号变得更加重要。信号能识别出第二个版本更接近但仍然不完整。它能注意到还有什么不对。也许计划错过了一个边界情况。或者例子让人困惑。如果工作流程不符合人们的实际工作方式呢？有时最重要的判断是决定一个功能根本不应该存在，即使它在技术上可以工作。

这对那些理解代码周围工作的人来说，是一种与软件的新关系。

我会在周五的直播中深入探讨这一点。GitHub、智能体，以及软件构建的新方式。在这里注册加入：hiten.com

GitHub 是 AI 工作必须变得可问责的地方

一个聊天窗口能让 AI 输出看起来完成得很好，因为文字干净，模型听起来自信。GitHub 提出了另一套问题：什么变了，为什么变，谁审查了，什么坏了，什么合并了，什么回退了，以及以后别人要维护什么。

这就是为什么 GitHub 现在更重要了。

AI 可以快速生成东西。展示工作并让他人容易审查则更难。一个变更必须经过一个流程。它可能从一个 Issue 开始，最终变成拉取请求、审查、合并、发布说明或用户报告。每一步都留下痕迹，让工作可见且可问责。

对工程师来说，这从来都是常态。对其他人来说，GitHub 常常看起来像一个带登录页面的代码仓库。AI 给非工程师提供了一个实际理由去理解内部发生了什么。

价值在于学习判断力在哪里进入软件工作。也意味着学习弱判断力如何为他人制造清理工作。

清晰是一种真正的贡献

非工程师的第一个有用贡献往往是清晰。

一个精确的 Issue 可以阻止团队解决错误的问题。好的重现步骤可以节省某人的猜测时间。客户上下文可以解释为什么一个看起来很小的 Bug 实际上与信任、转化、上手、留存相关。清晰的 README 可以防止同样的困惑扩散。好的计划可以为智能体和队友指明路径。

这是软件工作，因为它改变了决策的质量。

这个认识很重要，因为很多非工程师假设 GitHub 只有在他们能读代码时才有用。我认为第一个有用的层次是了解软件工作如何流动。问题被识别并清晰地定义。上下文被捕获在 Issue 中。Issue 变成计划，计划变成拉取请求。在此过程中，讨论改进工作，审查测试假设直到获得信心。

判断力一直是软件的一部分。只是当它活在会议、Slack 线程、客户电话和某个人的脑海里时，很容易丢失。

GitHub 是一个可以让判断力变得持久的地方。

糟糕的版本让别人付出不确定性代价

AI 使得创造量变得容易，而 GitHub 让这个量变得可见。这个组合会产生很多垃圾。

一个草率的 Issue 仍然浪费维护者的时间。一个由智能体编写的拉取请求，为一个人省下十分钟，却让另一个人多花一小时，这是带着差异的债务。一个没有重现步骤的 Bug 报告，是格式化得更好的不确定性。

最糟糕的 AI 贡献之所以失败，是因为它们把不确定性转移给了别人。它们看起来像工作，却在创造更多工作。

有益的贡献则相反。它消除猜测，添加上下文，解释发生了什么，缩小下一个决策范围，让工作更易于检查。AI 产出越多，这一点就越重要。量使得弱判断力变得昂贵，因为有人必须从中筛选。

对非工程师来说，标准是具体的：带来维护者没有的上下文。精确描述行为。测试你能观察到的东西。命名失败模式。给出例子。让下一个决策更容易。

这是有用的工作。

为什么我现在学它

我正在学 GitHub，因为软件工作的边界正在移动。

创始人、产品经理、运营人员、支持主管、营销人员和客户面对团队已经拥有智能体所需的上下文。客户痛点藏在每个请求背后，还有对解释在哪失效、哪些例子反映真实使用的理解。同样重要的是，这些团队能识别解决方案在技术上正确但错过了更大业务或产品目标的情况。

缺失的部分是让这些上下文变成持久工作的地方。

越来越地，那个地方是 GitHub。

我仍然不读代码，这现在更像一个值得围绕设计的约束，而不是忏悔。读代码是一种软件素养。理解软件工作如何流动是另一种。

改变的是，理解代码周围的工作变得更有价值，而非更少。AI 可以生成实现。但它不能告诉你哪个客户问题值得解决，哪个权衡重要，为什么一个功能会失败，或者结果是否真的改进了什么。这些问题仍然属于人。

这就是为什么我现在学 GitHub。GitHub 越来越成为想法变得可问责的地方。它是假设面对现实、决策被记录、工作被审查的地方，让关于什么真正有效的真相更难被忽略。

多年来，我的优势是找到线索。正确的搜索词、隐藏的 Issue、别人都漏掉客户洞察，常常带来不同。越来越地，优势在于知道线索属于哪里，以及如何将其转化为能在团队、产品和用户接触中存活的工作。

第一个有用的贡献常常是帮助团队充分理解问题，让正确答案能够浮现。一个客户投诉转化为清晰的 GitHub Issue 可以帮忙。添加缺失的上下文，解释问题为什么重要，或者定义成功应该是什么样子，也可以。这些贡献可以在任何人写代码之前改变工作的方向。这比仅仅找到变通办法或指向现有解决方案创造更多价值。

我会在周五的直播中更详细地拆解这一点，包括 GitHub 对用 AI 构建的非工程师意味着什么，以及如何培养这种软件素养。在 hiten.com 注册加入。