{"id":87195,"topic":"ai","source":"InfoQ-CN","title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","url_hash":"51769742769c6805da20580dbe4a415de89b80bf","author":"","summary":"人工智能时代的代码正在变为只写且可丢弃的 InfoQ-CN","content":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","image_url":"https://static001.infoq.cn/resource/image/66/84/66551yy42930097180533550d7697684.jpg","lang":"zh","published_at":"2026-09-21T06:03:16+00:00","fetched_at":"2026-09-21T13:15:07+00:00","status":"read","starred":0,"extract_state":"ok","summary_auto":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","cluster_id":null,"extract_retries":0,"extract_error":null,"contract_version":"news_item.v1","format_contract_version":"news_item_formats.v1","dedup_url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 1872 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":1872,"summary_length":1872,"usable_text_length":1872,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":1872,"summary_length":1872}},"news_item":{"id":87195,"canonical_url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","source_url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","source_name":"InfoQ-CN","author":null,"published_at":"2026-09-21T06:03:16+00:00","locale":"zh","topic":"ai","tags":[],"rss_summary":"人工智能时代的代码正在变为只写且可丢弃的 InfoQ-CN","full_text":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","excerpt":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","extraction":{"state":"ok","confidence":0.9,"error":null,"explanation":"High confidence: full text extraction produced 1872 characters.","diagnostics_url":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 1872 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":1872,"summary_length":1872,"usable_text_length":1872,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":1872,"summary_length":1872}}},"display_formats":["compact","card","full","digest_section","json"]},"daily_stack_record":{"title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","summary":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","source":"InfoQ-CN","date":"2026-09-21T06:03:16+00:00","content":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","confidence":0.9,"diagnostics_url":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","quality_bucket":"high","failure_kind":"none","retryable":false,"quality_reason":"High confidence: full text extraction produced 1872 characters.","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 1872 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":1872,"summary_length":1872,"usable_text_length":1872,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":1872,"summary_length":1872}},"tags":[]},"fallback_formats":["markdown","json","html"],"actions":{"read":"/item/87195","export_markdown":"/api/items/87195/export?format=markdown","export_json":"/api/items/87195/export?format=json","diagnose":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3"},"formats":{"full":{"id":87195,"title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","source":"InfoQ-CN","author":null,"published_at":"2026-09-21T06:03:16+00:00","locale":"zh","topic":"ai","tags":[],"excerpt":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","full_text":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","reading_time_min":1,"extraction":{"state":"ok","confidence":0.9,"error":null,"explanation":"High confidence: full text extraction produced 1872 characters.","diagnostics_url":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 1872 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":1872,"summary_length":1872,"usable_text_length":1872,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":1872,"summary_length":1872}}},"quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 1872 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":1872,"summary_length":1872,"usable_text_length":1872,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":1872,"summary_length":1872}},"actions":{"read":"/item/87195","export_markdown":"/api/items/87195/export?format=markdown","export_json":"/api/items/87195/export?format=json","diagnose":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3"}},"digest":{"id":87195,"title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","source":"InfoQ-CN","topic":"ai","published_at":"2026-09-21T06:03:16+00:00","excerpt":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。 Mortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：…","quality_bucket":"high","quality_reason":"High confidence: full text extraction produced 1872 characters.","reading_time_min":1,"cluster_id":null},"card":{"display_title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","subtitle":"InfoQ-CN · 2026-09-21","summary":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。 Mortimer 认为，在…","badges":["quality:high"],"links":{"read":"/item/87195","original":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","diagnose":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3"},"quality_warning":null},"export":{"title":"人工智能时代的代码正在变为只写且可丢弃的 - InfoQ-CN","url":"https://www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","summary":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","source":"InfoQ-CN","date":"2026-09-21T06:03:16+00:00","content":"Phillip Mortimer 在QCon London的演讲“软件工程中的复杂性与创造力”上指出，人工智能（AI）使所有代码都趋向于“只写且不可读的”。代码过于密集难以阅读，测试定义行为并成为文档。代码变成可丢弃的，重写往往比调试更容易。人工无法对大量 AI 生成的代码进行规模化审查。Mortimer 建议进行自动化审查并让智能体通过可观测性实现自我修复。意图与实现要进行解耦，开发者应更加专注于创造力。\nMortimer 认为，在 AI 时代，所有代码都是只写的。他引用了 Eric S Raymond 的话：\n“只写代码”是指那些深奥、复杂或结构混乱的代码，除了作者之外几乎无人能修改或理解，甚至作者自己也可能无法完全理解。\nMortimer 表示，某些语言从设计上就是“只写的”，它们以牺牲可读性换取极大的表达力与性能，他提到了 APL 与正则表达式。这类语言体现了由于极致密度导致的复杂性。\n应对这类代码的一个原则是让测试定义行为：\n当你写出的代码过于密集而难以阅读时，理解其行为的唯一方式是通过大量测试用例。测试成为了代码的文档。\nMortimer 说，你通过查看输入输出的组合来了解代码应当做什么，因为从代码本身很难直接看明白。\n另一个原则是代码可丢弃的。只写代码难以调试，通常从头重写比修改已有代码更容易。Mortimer 建议，保留测试，丢弃代码，重新实现。\nMortimer 指出，由于数量庞大，人工无法审查 AI 生成的代码：\n让人工逐行审查 AI 生成的代码没有意义，因为人很快就会成为瓶颈。\n他建议编写非常详细的测试并自动化代码审查。同时，他提出软件应具备自我修复的能力：\n一个强有力的做法是让 AI 编码智能体监听你的可观测性平台，在一定时间窗口内聚合告警，然后开始发起修复这些问题的 pull request，并从最常见的问题入手。\n我们应当将意图与实现解耦。Mortimer 表示，AI 使用自然语言，这使得开发者在不同编程语言间更具可迁移性。\nMortimer 认为，软件开发者如今的角色是创造力：\n创造力是迭代式的，它是在较长时间内逐步改进的过程。任何人都可以进行创造，关键是要开始动手。\nMortimer 主张拥抱“只写”的原则：AI 已经解决了实现问题，剩下的就是创造力。\n开发者喜欢编写软件，这是具有挑战性且激发思维的工作。Mortimer 说，他最喜欢的是解决问题和构建系统。现在是用软件构建的最好时代。意图与实现已完全解耦。他总结说，我们都是全栈开发者，你所需要的只是一个有创意的想法。\nInfoQ 在演讲后采访了Phillip Mortimer。\nInfoQ：如何实现自动化的代码审查？\nPhillip Mortimer：这相对非常简单直接，可以将编码智能体 harness 作为 CI action 来进行调用，并为其赋予资深开发者在审查代码时所关注的技能。代码审查智能体可以发布评论、请求修改，甚至批准 PR。\n你也许会认为让模型审查自身的输出并不会有什么好的效果，但我见过许多例子表明这一过程能提供非常有价值的审查意见，在代码部署之前就能找到缺陷。不同的提示词、不同的指令或不同的上下文似乎足以产生有价值的审查。实际上，这种对抗性审查过程正在更广泛的智能体系统中成为通用的技术，而不仅仅用于代码审查。\n代码审查智能体也可以在 pull request 流程之外运行，这有助于发现单个 PR 中不易被察觉的结构性问题。“去污（De-slopify）”类的智能体可以定期在代码库上运行，查找重复代码、未参数化的测试、未使用的特性标记或类似的低成本、低风险项并修复它们。\nInfoQ：组织可以采取哪些措施来培养创造力？\nMortimer：有创造力的人需要时间和空间来开展工作，要避免日常会议、交付和演示的干扰。他们往往也更适合独立工作，在企业界广受推崇的头脑风暴，实际上比个人独立思考产生的好点子更少。我倾向于把会议安排集中在一天的开始或结束，留出长时间的专注时段，这能让我不被打扰地处理困难问题。\n约束对创造性工作也很重要。约束消除了空白画布的无限可能性，迫使我们在有界空间内进行探索。我曾在一家名为 Accelex 的文档智能初创公司工作。早期我们受制于时间和资源，这迫使我为从表格中读取数据的问题寻找创新性地解决方案。\n创造力是长期累积的迭代性工作，而不是一次灵感迸发。拥有时间和空间进行创造性思考比以往任何时候都更重要，因为追求超高速交付使得人们更少有时间停下来反思和进行创造性思考。","confidence":0.9,"diagnostics_url":"/api/diagnose?url=https%3A//www.infoq.cn/article/Z3RA77AHmLro8zmY7Sl3","quality_bucket":"high","failure_kind":"none","retryable":false,"quality_reason":"High confidence: full text extraction produced 1872 characters.","quality_profile":{"profile_version":"extraction_quality.v2","bucket":"high","confidence":0.9,"failure_kind":"none","retryable":false,"retry_after_attempts":0,"reason":"High confidence: full text extraction produced 1872 characters.","operator_guidance":{"severity":"ok","recommended_action":"trust_full_text","next_step":"Use the extracted full text as the primary article source.","operator_label":"Ready","can_retry":false,"can_use_summary":false,"diagnostics_required":false},"content_depth":{"contract_version":"content_depth.v1","category":"full_text","label":"Full text","has_full_text":true,"has_summary":true,"content_length":1872,"summary_length":1872,"usable_text_length":1872,"source_field":"content"},"legacy_collapsed":false,"signals":{"extract_state":"ok","extract_error":null,"extract_retries":0,"content_length":1872,"summary_length":1872}},"tags":[],"format_contract_version":"news_item_formats.v1"}}}