今年接触不少产品、设计同学在反馈他们老板对其有 AI Coding 的要求（“产品也要写代码了”），有转技术的职业焦虑——部分研发对这种变化也存在明显怀疑；当然，还有一部分资深研发还处在“这 AI 生成的源码不能合并至生产分支吧”的犹豫中。

每一轮技术浪潮到来时，最先被冲击的往往不是能力不足的人，而是曾经太成功、太熟悉旧规则的人。

诺基亚和黑莓并不是不会造手机。恰恰相反，它们曾经代表了移动时代的工业成熟度、渠道能力和工程经验。但 iPhone 出现之后，手机不再只是通信设备，而变成了软件、触控、生态和体验的综合体。旧时代最坚固的船，在新海域里反而显得沉重。

AI Native 对研发团队的影响，也有类似意味。它不是在传统流程旁边多放一个 AI 工具，也不是让程序员写代码更快一点。它改变的是软件生产的基础设施。当代码生成、调研分析、设计草稿、测试补齐、文档沉淀都可以被 Agent 大规模参与时，团队真正需要重构的是人的角色、协作方式和价值定义。

旧舟：岗位分工的高效年代

传统的互联网项目团队通常由产品经理、设计师、研发（前后端、算法及运维等）、测试组成。产品定义需求，设计表达体验，研发完成实现，测试保障质量。这个模式并不落后，相反，它支撑了互联网行业很多年的高速发展。

因为在过去，人的能力边界决定了组织边界。一个人很难同时理解业务、完成设计、写出生产级代码、覆盖测试和保证上线质量；当设计稿和真实系统之间距离很远，测试又只能在后期系统性介入时，组织自然会把工作切成多个岗位，再通过评审、排期、联调、提测和验收串起来。

这种模式的价值在于稳定。它能让一个复杂项目被拆解，让不同专业的人在自己的深水区持续积累。很多优秀团队并不是因为分工而低效，相反，它们正是因为尊重专业分工，才得以守住质量。

这套体系里沉淀了很多值得尊重的东西：工程师对质量的坚持，测试对边界的敏感，设计师对体验的细腻，产品经理对用户问题的追问。传统岗位不是没有价值，它们代表了软件工业化过程中非常重要的一段历史。

但这种稳定的岗位分工，正在被 AI Agent 重新改写。

研发的转型

“古法”阶段

这个阶段的自我定位是研发工程师或“程序员”，视角聚焦在工程源码——在特定领域或岗位（比如前端、iOS/Android 移动客户端、Windows/macOS 桌面客户端、Node/Java/Python 后端、算法等等）去完成编码任务。

这个阶段 AI 的作用是辅助我们研发更高效率地写出更高质量的代码，比如 VSCode GitHub Copilot、Cursor 等。视角围绕在：

• 阅读、修改源码文件。
• 查找代码和问题。
• 生成代码、补全实现。
• 解释代码结构和修复错误。

AI 的作用本质还是一个 AI-first IDE 或 AI-enhanced IDE——“我正在写代码，你 AI 辅助我”、“我在一个 AI 原生 IDE 里工作”——给研发工程师使用的专业工具。

AI Coding 阶段

自我定位不再只是研发工程师“程序员”，而更像“交付责任人”。视角不再聚焦在工程源码本身，而是聚焦在交付结果：用户问题是否解决、产品行为是否符合预期。

这个阶段 AI 的作用也不再只是辅助我们“更快写代码”，而是可以作为一个能读仓库、改代码、跑命令、查资料、做验证、产出 PR、甚至并行处理任务的 Coding Agent。比如 Codex、Claude Code、Cursor Agent、GitHub Copilot Coding Agent 等。视角围绕在：

• 描述目标、背景、约束和验收标准。
• 让 AI 理解仓库、定位问题、提出实现方案。
• 让 AI 执行编码、重构、测试、验证、修复。
• 审查 AI 的计划、diff、测试结果和风险判断。
• 将临时任务沉淀为 Spec、测试、文档、架构约束。

这里会出现两种典型工作方式：

Vibe Coding 更适合探索阶段。研发不一定先写清楚完整需求，而是通过自然语言、截图、运行反馈、体验感觉持续引导 AI：“做个大概像这样”“这个交互不顺”“再简洁一点”“先跑起来看看”。它的价值是快速把想法变成可运行原型，适合 Demo、试错、灵感验证和低风险个人工具。

Specs Coding 更适合交付阶段。研发先把目标、边界、输入输出、异常场景、验收用例、测试要求写清楚，再让 AI 按规格实现。它的价值是降低歧义，让 AI 的输出可以被审查、验证、复用和长期维护，适合生产功能、复杂系统、多人协作和高风险改动。

维度	Vibe Coding	Specs Coding / Spec-Driven Development
起点	一个想法、感觉、目标。	明确规格、约束、验收标准。
Prompt 风格	“帮我做个像 X 的页面，感觉要顺一点”。	“输入/输出、状态、边界、错误、验收用例如下”。
人的角色	导演、试用者、即时反馈者。	产品/架构/测试/审查者。
AI 的角色	快速生成、快速改、快速试。	按合同实现、补测试、验证一致性。
成功判断	看起来对、跑起来行、体验顺。	符合 spec、测试通过、边界明确。
适合	原型、Demo、个人工具、探索 UI/交互。	生产功能、多人协作、长期维护、复杂系统。
风险	容易“能跑但不稳”，隐含需求丢失。	前期慢一点，但返工少、可审查。
文档沉淀	通常少。	Spec 本身就是长期事实源。

采用 Specs Coding 模式大部分研发其实已经在开始承担类似产品（需求分析）、测试（交付质量）等相关领域的事项责任了。产品、设计、研发及测试等岗位角色开始转型为 产品设计工程师 PDE(Product Design Engineer，即承担产品、设计、研发、测试等各个项目岗位职责)。

本质上，AI Coding 不再是一个单纯的 AI-first IDE 或 AI-enhanced IDE，而是一个 Agent-first Engineering Workflow：

不是“我正在写代码，你 AI 辅助我”，而是“我要交付一个结果，你 AI 和我一起规划、实现、验证、收口”。

研发的核心能力也随之变化：从“落地每一行代码”升级为“准确描述问题、设计约束、选择路径、审查结果、控制风险、沉淀长期事实”。代码仍然重要，但它从工作的中心，变成了交付链路中的一个产物。

OPC/OPT 阶段

OPC/OPT 即 One Person Company / One Person Team 简称。

自我定位进一步变化，更确定是“端到端交付责任人”。一个人不再只完成某个岗位上的工作，而是通过 Agent Team 承担原本需要一个小团队甚至一个公司的多角色协作。

这个阶段的关注点不再是源码，也不只是单次交付结果，而是如何构建一套可持续运转的个人生产系统。人要设计目标、上下文、流程、约束、验收和反馈回路；Agent 则承担大量可拆解、可工具化、可验证、可并行的工作。

可以类比那句“凡是能被 JavaScript 实现的，终将被 JavaScript 实现”。在 Agent 时代，大量知识工作也会经历类似迁移：

凡是能被清晰描述、拆解、工具化、验证和迭代的工作，终将被 Agent 化。

这个阶段 AI 的作用不再是一个助手，也不只是一个 Coding Agent，而是一组可编排、可协作、可复用的 Agent Team。它不一定要按岗位拆成多个独立 Agent，更像三类能力被随时调用：探索类能力负责梳理需求、竞品、用户场景和资料；交付类能力把交互、代码、脚本、自动化和文档做成可运行产物；保障类能力持续审查 diff、测试边界、安全风险、上线反馈和长期维护性。产品、设计、研发、测试这些名字会保留，但在 Agent Team 里，它们更像可组合的能力模块，而不是固定岗位。

人的核心工作也随之上移：先定义目标和成功标准，再提供足够清晰的业务背景、用户画像、代码仓库、历史决策和约束条件；然后设计 Harness，让 Agent 在有工具权限、有检查入口、有质量门禁的环境里工作；最后由人来判断优先级、品味、风险和最终责任，并把一次成功经验沉淀成模板、规范、技能、Agent 配置和长期事实源。

这里的关键词是 Context + Harness。

Context 决定 Agent 是否知道该往哪里走。它包括需求规格、架构文档、代码地图、设计原则、历史背景、用户反馈、反例、验收标准等。上下文越清晰，Agent 越像团队成员；上下文越模糊，Agent 越像随机外包。

Harness 决定 Agent 是否能安全、稳定、可验证地完成工作。它包括工具调用权限、沙箱、MCP、CI、测试命令、review 流程、日志、回滚机制、成本预算、人工确认点等。没有 Harness，Agent 能力越强，失控半径也越大。

所以第三阶段的本质不是“一个人干更多活”，而是：

一个人搭建一套由 Agent 参与运转的微型组织。

相比前两个阶段：

• 古法阶段：人写代码，AI 辅助。
• AI Coding 阶段：人定义交付，AI 参与实现。
• OPC / OPT 阶段：人设计系统，Agent Team 持续产出。

人的能力重心也再次升级：从编码能力，升级为交付能力，再升级为组织能力。只不过这里被组织的对象，不再主要是人，而是 Agent、工具、上下文、流程和验证系统。

这意味着，如果一个人的工作模式长期停留在被动接收任务、只完成局部交付、缺少主动补位和结果牵引上，会面临更大的转型压力。AI Native 更需要人具备问题定义、跨环节协同和结果闭环意识。

另一方面，大量个人 Agent 能力也会逐步演变成组织 Agent，比如某个业务线、项目组的数字员工。如果已有相关 Agent 或数字员工，可以将其招募至自己的 Agent Team。

组织的转型

绝大部分产品、设计、研发、测试会收敛成 PDE

前面已经说过，传统岗位分工不是低效的代名词。它在人的能力边界清晰、工具能力有限的时代，帮助团队把复杂项目拆开，让产品、设计、研发、测试分别在自己的深水区积累专业性。AI Native 团队组织的核心变化，也不是“人人都去写代码”，不是代码生成更快，而是许多过去被岗位门槛隔开的工作，开始可以被同一个人借助 Agent 串起来。

因此，在 AI Native 团队里，产品、设计、研发、测试会逐渐聚拢为一种更综合的能力形态 PDE。PDE 负责问题定义、方案选择和结果闭环；Specialist 则是在复杂架构、性能、安全、质量建模、体验系统、领域算法等深水区继续拉高上限，本质上是更高阶的 PDE；Harness 负责让人和 Agent 都能在项目里稳定工作。传统岗位的专业能力优势不会消失，具备更扎实基本功的人反而能更好地驾驭 AI Agent，只是岗位壁垒被 Agent 打破了。

针对技术深水区——产品、设计转研发面临巨大的“转型”压力，部分研发可能对这类转型存在严重怀疑。转型的关键仍然是“扬长补短”。项目的上限如果是技术瓶颈，团队的大多数人就要向技术深水区靠近；如果项目的上限是产品品味、审美和体验，团队的大多数人就要提高自己的产品判断和审美能力。所谓转型，不是放弃自己的优势，而是围绕这自身的优势发挥到项目真正需要的地方。

需要注意的是大部分项目的瓶颈可能不是技术，而是产品审美——这个是很容易被忽视的。

Harness：打造让 Agent 可靠工作的环境

如果 PDE 解决“谁来推动问题闭环”（负责把问题推进成结果），Harness Engineer 则解决“这个闭环如何可靠发生”（负责让这个推进过程可重复、可验证、可维护）。

Agent 很强，但没有上下文、边界和检查的 Agent 只能猜。猜对时像魔法，猜错了就是技术债。Harness 要处理的正是这些失败模式。

Harness Engineer 与传统 DevOps、Platform Engineer 有重叠，但关注点更偏向 AI Native 的工作环境：Agent 开工前读什么，长期事实源在哪里，任务如何表达，哪些工具可以用，哪些边界不能碰，如何验证结果，如何回滚，如何记录失败模式。

可以把 Harness 拆成五部分：

• Context：项目背景、架构边界、业务规则、代码地图、历史决策。
• Rules：编码规范、目录职责、权限边界、禁止事项。
• Tools：可调用的命令、MCP、脚本、调试入口、数据环境。
• Checks：测试、lint、类型检查、构建、回归、验收标准。
• Feedback：日志、报错、review、CI 结果、用户反馈、上线观察。

没有这些，AI Native 只是个人技巧。有了这些，Agent 才可能成为团队能力。

在存量项目中，Harness 尤其重要。多 Git 仓库、知识库分散、历史文档过期、接口契约不清、上下文藏在人脑里，这些都会让 Agent 的能力大幅折损。一个只有资深研发才能安全修改的项目，本质上说明它还依赖大量隐性知识。AI Native 不是把旧项目外面套一层 Agent，而是把项目改造成新人和 Agent 都能理解、修改、验证和演进的系统。

因此，组织需要把分散的项目资产收拢起来，用 Harness 把上下文、约束和验证路径加固，让 Agent 能够在稳定环境里工作。

一个 Dumbo 案例：从问题反馈到诊断闭环

Dumbo 是一个办公协作领域的桌面项目，日常会承载沟通、协作、工具调用和本地工作台等复杂场景。这里不展开它的具体业务细节，只拿其中一个很常见的能力举例：用户遇到业务问题时，如何把“我这里不对”变成研发可以复现、定位和修复的问题。

在传统流程里，这类需求通常会被拆成几段：产品先定义反馈入口和用户路径，设计补录制器交互和状态提示，研发实现窗口选择、录制、日志、网络和性能证据采集，测试再补目标窗口关闭、录制超时、打包失败、隐私边界等异常场景。这个分工并没有错，但真正困难的地方不在某一段实现，而在于这些判断能不能稳定地串成一条闭环：用户能否低成本提交有效证据，研发能否拿到足够但不过界的信息，系统能否在异常情况下仍然保留可诊断现场。

如果按 AI Native 的方式推进，这个任务更像由一个 PDE Owner 牵头完成闭环。Owner 先把用户问题、非目标、隐私边界、验收标准说清楚，例如录制必须由用户主动开始，必须明确选择目标窗口，最长只保留有限时间，只生成一个本地诊断包，敏感内容不进入默认采集范围，最终仍由用户手动提交。随后，再让 Agent 参与实现悬浮录制器、目标窗口选择、证据打包、异常状态、测试补齐和文档同步。人的工作不是逐行包办每个模块，而是持续校准体验、边界和风险。

这时 Harness 的作用就很明显。产品文档说明用户可见行为和隐私边界，架构文档说明代码应该落在哪些模块、哪些接口不能越界，执行计划记录阶段目标、风险和验证路径，检查命令保证文档、类型、测试和格式没有被绕过。Agent 可以写很多代码，但它要在这些边界里工作；人也不再只做口头验收，而是把判断写回文档、测试和规则，让下一次类似任务更容易被安全推进。

这个案例说明，AI Native 不是把产品、设计、研发都混成同一种旧岗位，也不是让每个人都去手写底层代码。真正的变化是，不同背景的人都可以把自己的判断放进同一个可运行、可验证、可维护的系统里。一个办公场景里的问题反馈能力，最后不只是一个录制器，而是一套从用户问题、体验路径、证据边界、工程实现到研发排查的闭环。

组织边界从岗位边界变成业务（问题）边界

前面已经提到传统组织通常按专业切分：产品负责“要做什么”，设计负责“怎么体验”，研发负责“怎么实现”，测试负责“是否可靠”。一个需求进入团队后，常常沿着岗位流水线移动：先被写成需求，再变成设计稿，然后进入研发排期，最后交给测试兜底。

AI Native 团队更适合按问题切分。谁最理解这个用户问题，谁就牵头把需求、体验、实现、验证串起来。团队不再只以“前端组、后端组、测试组、设计组”作为组织单元，而是围绕一个业务目标临时组装小型交付单元：由 PDE Owner 定义问题和验收标准，把上下文交给一组可调用 Agent，并持续审查它们的输出。这个单元的终点也不再是“代码写完”或“提测完成”，而是从发现问题到上线验证形成一条闭环链路。

这意味着，组织分类的重心会从岗位边界转向业务问题边界。

项目管理关注点发生变化

传统项目（业务）负责人更多盯资源投入和流程进度：人力是否够、排期是否合理、需求吞吐是否稳定、各岗位是否按时交付、提测质量和上线时间是否可控。到了 AI Native 阶段，这些仍然重要，但已经不足以解释一个团队的真实交付能力。

管理对象	传统项目更关注	AI Native 项目还要关注
投入	人力、排期、岗位进度	Agent 可执行性、工具权限、成本预算
需求	需求吞吐、上线时间	Spec 清晰度、上下文质量、验收标准
质量	提测质量、缺陷率	自动化验证覆盖、Harness 完备度、人工审查效率
资产	项目经验依赖核心成员	经验是否沉淀为长期事实源、模板和可复用 Agent 能力

所以，项目管理的关注点也会随之变化。只看千行源码缺陷率、需求吞吐和上线节奏，已经无法清晰衡量 AI Native 团队的真实交付品质。

回到旧舟与新海

开头说旧时代最坚固的船，在新海域里反而显得沉重。放在产品研发组织里，这艘“旧舟”不是某个岗位，也不是某类人，而是一整套按岗位流转、按工时排期、按交付节点验收的组织习惯。它在过去有效，也仍然有价值；只是当 Agent 开始承担越来越多执行工作时，真正决定速度和质量的，已经从“谁来写完”转向“谁能把问题、上下文、执行、验证和责任组织起来”。

所以，AI Native 组织转型不是给每个人配一个 AI 工具，也不是要求所有人变成同一种角色。新海里的核心能力，是让问题有人负责、上下文可以被复用、执行可以被 Agent 放大、验证可以自动发生、责任仍然清晰落在人身上。人不因为 AI 变得不重要，人的判断反而更靠前、更集中，也更难被流程替代。

真正值得建设的，不是一艘看起来更快的旧舟，而是一套能在新海里持续航行的组织方式：以问题为边界，以 Harness 为基础，以 Agent 为执行放大器，以人为最终判断和责任中心。能完成这个转向的团队，才会把 AI 从个人效率工具，变成组织级生产力。

霍桑给了海丝特·白兰一枚红字，却没有给她一个答案。

那枚“A”缝在胸前，代表通奸，代表耻辱，也代表一个社会对越轨者的公开宣判。海丝特却把它绣得精致华美，金线勾边，针脚细密，像一朵盛开在耻辱上的花。她承受着被宣判的处境，却仍然选择活得有形状。字母的含义由别人规定，针脚却出自她自己的手。

那枚红字，究竟是别人给她的，还是她自己的？

有些罪名来自外部。它有施罚者，有宣判，有被强加在身上的名字。你可以反抗它，承受它，改写它，或者像海丝特那样，把它绣成花。施罚者以为自己已经定义了你，你却仍能用后来的行动，改变那个名字的含义。

另一些罪感藏在内部。没有人将它缝在胸前，它只是在某个深夜悄悄生长，长进皮肤里，直到你难以分辨它究竟是身上的伤，还是自己原本的模样。你找不到一个可以反抗的对象，也不知道该从哪里将它取下。起初，你追问自己做了什么；后来，连追问也变了：这是我做的，还是我本来就是这样的人？

牧师丁梅斯代尔在布道台上以“罪人”自居，信众以为那是谦逊，却不知道他在用真话说谎。他说出了罪，却隐去了自己的那一份。每一次忏悔都使他更受敬重，也使那个不能说出的秘密更难开口。身体日渐枯萎，他仍站在布道台上，越来越难分清自己是在忏悔，还是在表演忏悔。

司马迁在《报任安书》里写下：“每念斯耻，汗未尝不发背沾衣也。”刑罚已经过去，身体仍在回应它；一百三十篇《史记》，也未必足以安放那份羞耻。

齐灵沃斯把痛苦转成了复仇。他知道自己在折磨牧师，也让受害者的身份成为报复的理由。只要那个人仍在受苦，他似乎就不必回头看自己。牧师死后，他迅速枯萎。他将生活的全部重量压在另一个人身上，那个人消失了，仇恨也就失去了支撑。

胸前的字可以被看见，心里的那一枚却很难辨认。你起初清楚地知道：这是别人给我的，这不是我的错。可时间一长，那个名字开始出现在每一次自我审视、退缩和回避里。你慢慢无法确定：我是因为那枚红字而变成了这样，还是我本来就是这样，它只是照出了真相？

施罚者不必再开口。你会替他追问，替他寻找证据，又替他作出判决。即使已经离开那些人的视线，你仍会在开口前迟疑，在无人指责时先为自己辩解。镜子里只有一个人，审判却没有停。

海丝特也承受过这种变化。长年的孤独和惩罚，使她原有的柔情与生气渐渐枯萎。胸前的字越来越像她全部的身份，旁人看见的是一个道德符号，她也越来越难从那目光里看见自己。

嵇康临刑前索琴，弹完《广陵散》，留下那句：“《广陵散》于今绝矣。”曲声随他而止，仿佛连那个尚未被刑罚定义的自己，也一并收了回去。

更多的人仍要带着那个名字活下去。他们渐渐用它解释自己的退缩、失败，甚至解释那些与它无关的事，最终活成了别人最初定义的形状。那个名字使人受苦，也替人省去了重新理解自己的茫然。人有时太需要一个关于自己的故事，别人给了一个，哪怕是关于罪的，也会在不知不觉中将它收下。有一个解释，似乎总好过没有。

郑庄公等弟弟走到可以讨伐的地步，后来又在隧道里与母亲相见，赋诗曰“大隧之中，其乐也融融”。《左传》解释那个“克”字，说的是兄弟“如二君”。

齐灵沃斯知道自己在复仇。郑庄公的故事却让人看见另一种可能：一个人可以为自己的等待找到足够正当的理由，也可以真诚地为重逢欢喜，而不再追问自己是否曾希望另一个人走到绝路。“融融”仿佛盖住了一切，那个“克”字却还留在那里。

赎罪究竟是什么？

它不是忏悔，不是惩罚，也不是用更大的善行抵消过失。纠缠之中，赎罪首先是一个艰难的辨认动作：把外部强加的和自己应当承担的，一针一线地拆开，看清楚哪些是别人的线，哪些是自己的。

拆开之后，你可能同时发现两件令人不安的事：外部强加的比自己以为的更多，自己背负了太多本不属于自己的重量；而有些过失又确实出自自己，不能全推给那枚红字、那个施罚者、那个时代。

一个发现令人愤怒，另一个令人羞耻。愤怒之后是什么，羞耻之后又是什么？辨认本身不提供出口，它只是让你更清楚地看见那个没有出口的处境。

海丝特晚年回到那个小镇，自愿重新戴上红字。它在旁人眼里已从耻辱变成值得敬重的标记，但这仍不能替她回答：胸前这枚字母，如今有多少属于自己？

那枚红字，从来不只是海丝特的。每个人的胸前，都有一枚尚未被命名的字母——是别人给的，还是自己的，有时候连自己也分不清。

霍桑只是让那枚字母悬在那里。

写于2026年盛夏

被围起来的数字生活：从数字地主到数字佃农——一场主权收缩的困局。

你购买设备的那一刻，未必已经签下卖身契，但你很可能已经接受了一套由别人预先写好的规则。

当你点亮新手机的屏幕，面对的往往不是一片待你开垦的数字旷野，而是一座早已规划好路线的高墙花园。你想安装一个来自网络的软件，系统彬彬有礼地提醒你：“请从官方应用商店下载。”你想修改系统设置，那选项灰暗如铁窗，上书“已被管理员禁用”。你想将照片直接传输到电脑，却被引导进入某个特定应用，再经由云端中转——仿佛你不过是数据的临时保管者，而非真正的支配者。

这一切，并不只是技术进步的自然结果，也不只是某一家公司的恶意设计。它更像是一种结构性合流：资本追求可持续抽租，平台追求更高的可控性，监管追求更低的风险与更清晰的责任边界，而大量普通用户也真诚地偏好“少一点折腾、最好默认可用”的产品体验。几股力量彼此借力，最终共同塑造了今天这座看似便捷、实则不断收缩用户主权的数字花园。

问题恰恰在这里：秩序、便利与安全并非没有价值，但当它们被组织成一套默认设置、且越来越少给用户留下退出、迁移和自行决定的权利时，我们在数字世界中的身份就发生了悄然变化。至少对那些仍然重视控制权、迁移权和自我支配能力的人来说，这种变化已经不是“体验优化”，而是一场温和而持续的身份降格：我们正从拥有者，退回到被许可使用者；从主人，退回到租客。

更棘手的是，这种变化并不总以暴力的方式出现。它往往披着“为你好”的外衣，以安全、体验、一体化服务、持续更新的名义完成。于是，真正值得警惕的，不只是某一家公司太强势，而是我们越来越习惯于把原本属于自己的决定权，交给平台代为处理。

一、从数字旷野到围墙花园：谁拿走了你的主权？

曾经，个人电脑代表着一种近乎粗粝却真实的自由。开机之后，你面对的是文件系统，是可见的目录，是可以自行决定安装与卸载的软件，是可以自由插拔的外设，是可以被替换、被修补、被折腾的操作系统。你不一定总能驾驭它，但至少你知道：机器的使用逻辑，原则上应该由你来定义。

那是一个远称不上完美的时代。软件可能崩溃，系统可能蓝屏，驱动冲突和兼容问题足以逼疯任何新手；可与此同时，你的设备仍是你的设备。你可以从任何网站下载安装程序，可以修改系统默认项，可以把文档拖进任何你喜欢的目录，可以决定数据备份到哪里，也可以在平台意志之外，维持一套属于自己的数字生活秩序。

诚然，那片旷野并非伊甸园。盗版软件横行，系统崩溃是家常便饭，驱动程序冲突足以让新手束手无策，病毒和木马在开放的旷野上肆虐。那时的“自由”，确实伴随着混乱、风险与更高的学习成本。开放，从来不是毫无代价的恩赐。

也必须承认，并不是每个人都渴望做“国王”。对很多普通用户而言，开放意味着更高的理解门槛、更频繁的故障、更难分辨真伪的风险。后来平台化系统之所以胜利，不只是因为它们更会控制，也因为它们确实把大量原本由个人承担的技术负担，重新打包成了“默认可用的秩序”。这正是它们最强的地方。

但问题不在于秩序本身，而在于这种秩序越来越少给用户留下真正的选择权。你可以不必亲自处理风险，却也越来越难决定软件从哪里来、数据往哪里去、系统应该如何被使用。你得到的是省心，失去的却是支配权。自由不再被明面剥夺，而是在“替你做好了”的过程中，被一层层拿走。

二、平台化的圈地：资本、安全与便利如何共同构建数字庄园

平台时代的形成，并不是一场单线程的阴谋，而是一场多方力量彼此强化的结果。资本当然希望把一次性交易改造成长期抽租，平台天然偏爱标准化、可审计、可封禁、可分成的秩序；监管机构偏爱更容易追责的集中式入口；而大量普通用户，则真实地偏爱“少一点折腾、最好默认可用”的产品体验。

问题恰恰在这里：这些诉求并非完全虚假，甚至各自都有其现实合理性。但当它们叠加起来，结果却稳定地指向同一个方向——控制权持续从用户手中转移到平台手中。于是，我们看到的，不只是某个资本集团的贪婪，而是一种更稳固的结构：资本逐利、安全治理、规模化运维与便利偏好，共同塑造了今天的数字庄园。

在这种结构里，资本仍然是最强势的组织者。它最懂得如何把“便利”变成依赖，把“安全”变成授权，把“服务”变成租金，把“默认设置”变成新的服从关系。于是，一场针对用户主权的系统性收缩徐徐展开。

2.1 从买工具到租服务：所有权如何被抽空

过去的软件交易，更接近传统商品逻辑：你买下一个版本，获得一个副本，在本地安装，在本地使用。它可能过时，可能不再更新，但至少在一段时间内，它属于你。

而今天，越来越多的软件与服务转向订阅制、账号制、云端授权制。你支付的，不再是“拥有这个工具”的价钱，而是“继续被允许使用它”的租金。只要你停止付款，访问权就会收回，某些功能会熄火，某些内容会失效，某些积累甚至可能一并消失。

这并不意味着订阅制毫无合理性。持续更新、云同步、协同编辑、安全补丁、跨设备服务，这些确实构成了新的成本结构。但真正的问题是，当产品从工具转变为持续服务时，用户却没有同步获得足够明确的退出权、迁移权与最低限度的访问保障。于是，订阅不再只是商业模式，也逐渐成为一种支配关系。

2.2 从开放网络到平台内网络：便利如何变成依附

平台告诉你：这是为了方便，为了让你无需下载多个 App，无需记住多个密码，无需在不同服务之间反复切换。必须承认，这种便利并不是幻觉。统一登录、统一支付、低学习成本、弱设备门槛，这些都是真实的优势。对很多用户来说，这甚至是他们第一次如此低摩擦地接入数字服务。

但便利的另一面，是平台替你决定了连接方式、数据去向和服务边界。你不再面对一个开放互联网，而是在“平台里的互联网”里活动；你不再拥有可自由迁移的记录与关系，而是在平台内部“被允许使用”这些积累。问题不在于便利本身，而在于便利被设计成了依附：你越离不开它，就越难带着自己的关系、记录与资产离开它。

2.3 从用户到行为矿工：数据如何反过来定义你

平台经济的另一重逻辑，是把用户的一切行为都重新编码为可采集、可分析、可出售、可训练的资源。点击、停留、搜索、支付、聊天、观看、滑动，每一次动作都被记录并回流进更庞大的推荐、广告、画像与优化系统之中。

表面上，你获得了更懂你的服务；实际上，你也在不知不觉中为平台持续生产价值。更微妙的是，这些数据并非只是“被平台收集”，它们也在反过来塑造你能看到什么、会买什么、会信什么、会习惯于什么。用户不仅成为平台的消费者，也成为平台不断再生产自身权力的原料。

三、当开放互联网开始后退：我们失去了什么？

我们失去的，并不只是几个下载入口，或几个自由安装软件的权限。更深层的丧失，是一种曾经默认存在的技术伦理：设备应当首先服务于拥有它的人，软件应当允许被替换，数据应当能够被导出，服务之间应当可以互相连接。

一旦这些原则退场，用户就不再是系统的主人，而更像平台秩序中的临时居住者。你可以住得舒适，但装修权、改造权、迁移权、继承权，越来越不掌握在你手里。

开放互联网的价值，不只在于“自由折腾”，更在于它曾经提供了一种制衡机制：任何平台若做得太差，用户还有较低成本的替代路径。可一旦入口、关系链、支付能力、身份认证与数据沉淀都被集中到少数平台内部，这种制衡便会迅速减弱。你依然看似拥有选择，实际上却越来越难真正离开。

四、AI Agent 会成为新的破墙工具，还是新的包租人？

近来像 OpenClaw 这样的工具之所以引人注目，正因为它提出了一种新的可能：如果平台不愿开放接口，AI 是否可以绕过 API，直接通过“看见屏幕—理解界面—模拟点击”的方式替用户重新取得操作权？

这确实是一种富有想象力的突围。它意味着，即便平台封死了官方接口，用户仍可能借助模型在交互层面重新进入系统，把原本被平台垄断的流程重新纳入自动化范围之中。从这个意义上说，Agent 技术似乎为“重新夺回主动权”打开了一条缝隙。

但这种缝隙并不自动通向解放。因为一旦 AI 代理代替用户操作应用，新的问题会立刻出现：谁来控制这个 Agent？谁来承担误操作责任？谁掌握它读取界面、分析上下文、保存凭证和访问敏感信息的权限？如果这些能力最终集中到另一个模型平台手中，那么旧平台的围墙也许只是被绕过了，新的中介秩序却很可能随之建立。

所以，Agent 不是天然的解放工具。它可能成为用户重新争夺操作权的杠杆，也可能只是“房东换了一个”的下一轮租赁关系。它的政治含义，不在于它看上去多么酷炫，而在于它会把控制权重新交还给谁。

五、我们何以无力翻身？——制度性约束与结构性困境

OpenClaw 的局限，折射出一个更深层的困境：平台体系对用户主权的压缩，往往是制度性的、结构性的，而我们的反抗则常常只是技术性的、局部性的。

这种围墙花园，不仅是技术层面的限制，更是法律、经济、组织与心理层面的多重裹挟：

• 法律上，用户协议为平台提供了近乎天然的护身符。你每一次点击“我同意”，都在接受一套单方面拟定的秩序。这些协议冗长晦涩，但一旦发生纠纷，它们往往又成为平台最可靠的防线。
• 经济上，切换成本高得惊人。你的文件格式、工作流程、社交网络、历史数据、支付记录，全被锁进既有生态。离开并非不可行，只是代价极高。
• 组织上，平台不仅服务个人，也嵌入企业、学校、政务与日常协作。你未必真心认同它，却很难单方面退出它。
• 心理上，越来越多人已把“方便”视为压倒一切的价值，把“默认可用”视为技术理应提供的状态。只要系统还能顺畅运行，很多人并不会主动追问自己究竟失去了什么。

还需要承认的是，“数字佃农”并不是所有用户都会主动认领的自我描述。有人把封闭生态体验为窒息，也有人把它体验为秩序；有人在意所有权，有人更在意随手可用；有人担心迁移困难，也有人从未打算迁移。率先感到不适的，往往是那些经历过开放互联网、重视可控性、习惯自行管理工具链的人。他们的感受未必在统计意义上最普遍，却常常在结构意义上最敏感——因为他们最早察觉到的，不只是“不方便”，而是用户正在从拥有者退回到被许可使用者。

更致命的是，平台之间虽然彼此竞争，但在维护“围墙逻辑”上却往往高度相似。苹果的封闭生态、谷歌的应用分发体系、微软的新平台野心，路径不尽相同，却都在强化一个基本趋势：把用户留在自有秩序中，让退出变难，让迁移昂贵，让控制权回收到平台侧。

面对这种结构性困局，个体当然不是毫无行动空间，但也很难靠一次越狱、一次换机、一次装开源软件就彻底脱身。问题不只是“有没有替代品”，而是我们的数字生活早已深嵌在一整套平台制度之中。

六、结语：从“数字佃农”到“数字公民”——问题不在于怀旧，而在于重新追问边界

回看这场围绕数字生活展开的缓慢圈地，我们看到的并不是一个简单的善恶故事。PC 时代的开放更粗粝，也更混乱；移动时代的平台化更整齐，也更省心。问题不在于过去天然更高尚，也不在于今天的一切便利都是骗局。真正值得警惕的是：当安全、便利、效率与商业逻辑被合并成一套越来越封闭的默认秩序，用户对设备、数据、软件和服务的支配权，便开始持续收缩。

从这个意义上说，“数字佃农”并不是一个适用于所有人的情绪标签，而更像是一种症状描述。不是每个人都会立刻为此焦虑，也不是每个人都愿意为更多控制权支付学习成本和风险成本。但一个社会若长期不再追问这些问题，用户就会在不知不觉中，从公民退回到租客，从拥有者退回到被许可使用者。

OpenClaw 的意义，也许正不在于它已经带来了真正的解放，而在于它暴露了今天数字秩序中的一个核心事实：即便平台不开放接口，用户依然会寻找新的方式夺回主动权；而每一次这种尝试，又都迅速暴露出新的依赖、新的风险与新的收编机制。它证明了反抗并非不可能，也证明了单靠工具远远不够。

所以，真正的问题或许不再是“怎样养好一只龙虾”，而是我们是否愿意重新把几个长期被平台替我们回答的问题，拿回公共讨论之中：

• 设备究竟归谁支配？
• 数据是否应当具备可携带权？
• 订阅终止之后，用户是否仍应保有最低限度的访问权？
• 平台以安全和便利为名收回的那些控制权，边界究竟在哪里？
• 哪些接口、哪些格式、哪些基础能力，应该被视作数字时代的公共设施？

真正的破局，不会只是某个工具突然横空出世，而是制度层面的重构：法律如何重新界定用户权利，市场如何降低迁移成本，社会如何重新理解“方便”与“自由”的关系，公众又如何重新认识“数据”“接口”“设备支配权”并非技术细节，而是数字时代最基本的公民问题。

或许，第一步不是要求所有人都立刻成为“数字主权”的信徒，而是重新学会对现有秩序提出怀疑。不是否认便利，而是拒绝把便利自动等同于正当；不是浪漫化开放，而是要求在秩序之中保留退出、迁移和自行决定的空间。

科技本应扩展人的能力，而不是把人稳定地安置在被管理的位置上。哪怕只有一部分人率先感到了这种收缩，他们的焦虑也未必只是怀旧，它更可能是某种前哨警报：提醒我们，数字世界的边界，正在被谁定义，又正在替谁服务。

---

温馨提示：本文基于ChatGPT工具辅助完成。