知乎话题总结：2026 年 OPC（一人公司）为什么不再是口号？

整理时间：2026-06-26
问题链接：https://www.zhihu.com/question/2030748379056190158
原始回答链接：https://www.zhihu.com/question/2030748379056190158/answer/2053773797631775981

读取范围

这次使用已登录知乎的内置浏览器读取，范围比上一版大很多。

• 问题页显示：951 个回答，163 个回答被折叠。
• 默认排序页：读取到页面直接展示的 5 条核心回答。
• 按时间排序页：从 2026-06-26 13:58 往前滚动读取到 2026-04-28 23:05，共保存 270 条回答。
• 本地原始采集文件：/Users/wyan/Downloads/zhihu_opc_time_answers.json

注意：本文档不是 951 条全量逐条复述，而是基于已读取的 270 条时间序回答和默认排序高赞回答做主题归纳、赞同数排序和判断。未读取部分主要是更早时间的回答、折叠回答，以及知乎未继续加载出的内容。

背景：需求澄清是一个被低估的成本中心

做过研发的人都知道，需求评审会结束后，研发真正动手写代码，往往还要经历一轮”追着产品问”的过程。这些问题有时候很小（一个按钮文案），有时候很大（整个业务逻辑是否成立）。问题问得晚，代价是已经写了一半的代码要返工；问题没问到，代价是上线后出 bug 或功能偏差。

我们在 Codelix 中尝试用 AI 来解决这个问题。本文记录了从立项到多轮迭代的全过程，包括遇到的坑、做的取舍，以及最终效果。

背景

Codelix 最初是为后台服务设计的 AI 编码平台：给一个 TAPD 需求单，AI 自动完成需求分析、方案设计、代码生成、编译校验、Code Review 全流水线。后台场景相对规整，踩坑踩了几个月后，我们开始把这套流水线推广到 iOS、Android、Kuikly 三个客户端平台。

这篇文章记录了整个过程的技术细节，包括 iOS pipeline 从零到可用，Kuikly 接入时踩的低级 bug，Android 的广撒网问题，以及跨三端做统一优化的五轮演进。

前言

从最早思考《为什么要做一个 iOS bug 自动修复的 agent 程序》，到 V3 把单文件原型重构成 AgentEngine 引擎、V4 把领域知识结构化、V5 把「完成需求开发」提成唯一 P0 并引入 Pipeline 编排基座，这个项目断断续续做了两个月。之前我写过一篇《从 Bug 修复到需求开发：iOS AutoFix Agent 的 V3-V5 演进之路》，把版本演进的脉络讲清楚了。

接下来我的重心会转到和其他同学共建另一个 Agent 项目上。所以趁记忆还热乎，给 iOS AutoFix 做一份阶段性收尾——这篇不再复述版本演进，而是把这一年踩过坑、验证过的与领域无关、可以直接搬到下一个 Agent 项目的工程经验沉淀下来。

从 Bug 修复到需求开发：iOS AutoFix Agent 的 V3-V5 演进之路

在上一篇文章里，我解释了为什么选择自建 Agent 架构，而不是做 IDE 插件——核心在于要拥有”流程控制权”，而不是”平台适配权”。

那篇文章写完后，系统先后经历了 V3、V4、V5 三个大版本的迭代。我打算在这篇里把这段演进过程讲清楚：每一版做了什么、为什么这么做、踩了什么坑、优化思路是什么。

问题现象

在 Android Studio 中 Build / Sync 报错：

1
2
3
4
5
6
7
8

Could not compile initialization script '.../ijMapper1.gradle'.
> startup failed:
  General error during conversion: Unsupported class file major version 65

java.lang.IllegalArgumentException: Unsupported class file major version 65
    at groovyjarjarasm.asm.ClassReader.<init>(ClassReader.java:199)
    ...
    at com.intellij.gradle.toolingExtension.impl.modelAction.GradleModelFetchAction...

从命令行直接执行 ./gradlew tasks 完全正常，只有通过 Android Studio 触发构建时才报错。

为什么要做一个 iOS Bug 自动修复的 Agent 程序

一、为什么不直接做 IDE 插件

如果目标只是”在 IDE 里更方便地写代码”，那直接基于 CodeBuddy 这类 Agent IDE 做插件，通常更快、更省成本。

但我的目标不止于此：

• 把”修复/分析/定位/验证”沉淀成可复用能力
• 让 Agent 不依赖某个 IDE 才能工作
• 把人的经验流程产品化、平台化、自动化
• 围绕 iOS 问题定位、日志分析、修复建议形成领域能力

这些目标决定了我需要一套自建的 Agent 架构，而不是一个 IDE 插件。

原文地址

近期，由小红书联合多伦多大学等高校的研究人员发布了 《SWE-Bench Mobile》（2602.09540） 论文，内容主要是评估 LLM 智能体在处理真实生产级移动端应用开发任务时的能力，并提出了首个针对该领域的基准测试——SWE-Bench Mobile。

这个论文对比之前那些简单的需求场景，明显更具备说服力，最重要的是，用真实的数据给目前的 AI 狂热浇一浇冷水。

工具概述

iOS Bug AutoFix 是一个基于 AI 的 iOS 代码 Bug 自动定位工具。它从自然语言 Bug 描述出发，通过三步流水线（信息提取 → 粗筛定位 → 精确定位）自动定位到问题代码的具体文件和行号。本次分析以两条实际命令的运行为例。