[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fmef3_dgpnaAa5uyppihc6jE0Vf7HF2yuvotcjcWW6fw":3},{"item":4,"related":54},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":43,"sourceName":44,"sourceUrl":45,"status":46,"seoTitle":47,"seoDescription":47,"canonicalUrl":47,"isFeatured":48,"sno":49,"sortOrder":50,"publishedAt":51,"updatedAt":52,"createdAt":53},"91a515bb-7b16-4b1a-9a13-8a579d689e00","article","软件复杂度分配：开发者和用户各自该承担什么","software-complexity","当开发者选择“不做某些事情”时，这些事情的复杂度并不会自动消失，而是会以另一种形式转嫁到用户身上","在数字产品领域大量的实践工作中，我们逐渐认识到：复杂度不会消失，它只会在开发者和用户之间转移。当开发者选择“不做某些事情”时，这些事情的复杂度并不会自动消失，而是以另一种形式——决策成本、学习成本、试错成本——转嫁到用户身上。\n\n于是我们开始强调：\n\n> 简洁不是简单，是极致的克制\n\n这句话的另一面是：每一种克制的背后，都有开发者多承担了一部分复杂度。\n\n## 复杂度正在被转嫁给用户\n\n一个最简单的例子：用户问 AI “今天天气怎么样”，得到回答“今天气温 28°C，晴，空气质量良。另外我注意到您的日程中有一场会议，是否需要提醒？您也可以开启天气推送服务，或查询未来一周天气。”——这看起来是“周到”，实际上是一次复杂度转嫁：用户需要从一段话中筛选出自己真正需要的信息，还要额外处理多个不请自来的决策分支。\n\n当我们追问“为什么 Agent 会这样回应”时，答案往往是：开发者没有在系统内部完成优先级判断，于是把所有信息都投喂给用户，让用户自己过滤。开发者逃避了“判断什么对用户更重要”的复杂度，用户则被迫承担“在海量输出中寻找答案”的复杂度。\n\n又例如许多产品热衷于展示“功能大全”——工具栏上排满图标，侧边栏塞满入口，首页堆叠各类模块。用户打开应用的首要任务变成了“先弄明白这些东西是干什么的”，而不是“开始做我想做的事”。开发者把“如何组织信息”的复杂度推给了用户，让用户充当自己的信息架构师。\n\n> 当用户需要先学习一套工具调用逻辑才能使用产品时，开发者只完成了 50% 的工作——实现功能，另外 50%——让功能在正确的时机出现——被丢给了用户。\n\n这种转嫁的后果就是认知负荷陡增。用户把大量精力消耗在“理解界面”上，而非“完成任务”上，产品再强大也变成了一种负担。\n\n## 开发者该承担什么\n\n开发者应该承担的是系统内部的全部复杂度。\n\nhttps:\u002F\u002Fsited.cn\n\n以静态页面托管网站Sited为例，复杂度包括：\n\n技术实现的复杂度。 传统静态网站部署往往涉及服务器、对象存储、目录结构、域名、HTTPS、CDN、构建配置等一系列概念。即使每一项单独来看都不算困难，这些概念的叠加也会形成相当高的入门门槛。而在 Sited 中，整个流程被压缩为三个阶段：“上传内容—配置设置—一键发布”。用户只需要上传文件、拖放文件夹、导入 ZIP 或直接粘贴内容即可完成部署。CDN 配置、SSL 证书、服务器运维、数据库优化——所有这些技术复杂度并没有消失，而是被我们留在了系统内部，用户不需要看到，也不需要理解。任何互联网产品都应如此：底层技术栈的复杂性，应由开发者封装好，只对外暴露最简洁的操作路径。\n\n情境判断的复杂度。 Sited 展示了一个重要的产品原则：简单的用户体验往往建立在复杂的工程实现之上。我们做的并不是删除能力，而是重新分配复杂度。在传统模式中，复杂度由用户承担；在 Sited 的模式中，更多复杂度被转移给系统。这意味着开发者需要做出判断：哪些技术细节是用户完成核心任务所必需的，哪些不是。对任何产品而言，这种情境判断的复杂度同样应由开发者承担——根据用户当前的操作场景，自动预测下一步需求，而不是把所有可能操作平铺出来让用户手动挑选。\n\n优先级排序的复杂度。 “极致的克制”真正克制的是让用户参与技术细节的冲动。开发者可能有能力向用户展示服务器状态、CDN 节点、SSL 配置和大量高级参数，但如果这些信息不是用户完成核心任务所必需的，就不应该因为“系统支持”而强迫用户理解。Sited 将网站部署压缩成上传、配置和发布三步，就是把大量基础设施操作转移给了系统。同样的逻辑适用于所有互联网产品：当产品拥有多个能力时，开发者必须在内部完成优先级评判——在当前场景下，哪些功能应该最显眼，哪些信息应该优先呈现——而不是把排序工作交给用户。\n\n错误处理的复杂度。 在 Sited 中，文件上传失败、部署超时、域名解析异常——所有这些技术故障的处理方案、降级策略、重试机制，全部由我们预先设计好，用户只会看到“部署成功”或“请稍后重试”这样清晰的状态提示，而不会面对任何错误码或调试信息。任何互联网产品都应如此：网络超时、数据格式异常、权限校验失败等所有技术层面的异常，都应该被转化为用户能理解、能行动的语言，而不是把堆栈跟踪或错误代码直接抛出。\n\n## 用户该承担什么\n\n用户需要承担的，仅限于与其目标直接相关的决策。具体来说：\n\n目标的陈述。 用户需要告诉系统“我想做什么”。这不是复杂度，而是使用任何工具的前提。\n\n关键参数的确认。 某些决策点必须由用户做出，因为系统缺乏必要信息。例如“发送邮件前确认收件人”“支付前确认金额”——这些是高风险的决策，需要人类承担责任。\n\n偏好的表达。 用户可以表达自己的使用习惯，例如“我喜欢简洁的界面”或“我需要高级模式”。但这些偏好应当是“设定一次，长期生效”的系统级配置，而非每次操作都要重复的指令。\n\n反馈和纠偏。 当系统判断错误时，用户需要能够纠正。但纠正本身应该是低成本的——点击一下“不对”或重新输入，而不是进入某个配置面板修改底层参数。\n\n除此之外的一切——功能选择、信息筛选、步骤规划、异常处理——都应该是系统的职责。\n\n## 复杂度分配失衡的放大效应\n\n互联网产品有一个共同趋势：版本迭代越久，功能越多，界面越拥挤，而开发者往往倾向于用“增加选项”来解决问题——新增需求就加一个新开关，新场景就加一个新入口。久而久之，产品就变成了一个复杂度的堆积场，而每一次堆积都在增加用户的理解负担。\n\n这种堆积之所以危险，是因为互联网产品的用户场景极其多样，开发者不可能预料到每一种用法，于是就用“把控制权全部交给用户”来回避设计决策。但用户不是产品专家，他们只想完成自己的任务。当产品把选择权变成选择负担时，就已经失去了作为工具的基本尊严。\n\n互联网产品一旦形成“复杂就是强大”的认知惯性，就会陷入功能竞赛的囚徒困境，最终所有产品都变得臃肿难用，而最先做出克制的产品反而可能被贴上“功能太少”的标签。打破这种循环，需要开发者主动承担复杂度分配的职责，而不是随波逐流。\n\n## 结语\n\n回到我们的核心观点：简洁不是简单，是极致的克制。这句话的底层逻辑正是复杂度分配——开发者在系统内部承担了足够多的复杂度，用户才得以面对一个简洁的界面。\n\n我们相信，互联网产品竞争力的分水岭，不在于谁的功能列表更长，而在于谁更清楚地把复杂度留在了系统内部、把简洁留给了用户。用户打开产品的时候，他真正想要的不是看到一排排按钮和选项，而是事情被高效地完成了。\n\n让用户感知不到复杂性的存在，就是开发者对复杂度最好的承担。","\u002Fuploads\u002F2026-08-31\u002F00da97de-89e8-46ad-babb-19e7e09a5ff0.jpg",[],[],"Srces工作室","https:\u002F\u002Fsrces.cn","f39339b1-aaa6-4e86-b0c2-a6e6a21113b5",{"id":18,"name":19,"slug":20,"description":21},"c523f1c9-338c-4618-add9-9ce67a39b2a0","研究","research","研究成果与启发",[23,27,31,35,39],{"id":24,"name":25,"slug":26},"bfb9750c-40cf-487e-81ad-dbac5f22ffcd","SaaS","saas",{"id":28,"name":29,"slug":30},"93e74788-a474-46ff-a185-5bdb45ab3b02","Srces工作室产品","srces-product",{"id":32,"name":33,"slug":34},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":36,"name":37,"slug":38},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":40,"name":41,"slug":42},"a202d639-99a6-488a-a712-4d4c6ffd7e15","开发","dev","资料来源","www.srces.cn","https:\u002F\u002Fwww.srces.cn\u002F#paper","published",null,true,1,0,"2026-08-31T00:00:00.000Z","2026-08-31T07:59:11.127Z","2026-08-31T06:12:08.608Z",[55,64,73],{"id":56,"type":6,"title":57,"slug":58,"summary":59,"coverUrl":60,"authorName":14,"sno":61,"publishedAt":62,"createdAt":63},"2c8a2431-6be0-4189-8074-f332db448b3c","Sited 2.0 焕新上线：更现代、更安全、更优雅的静态网页部署平台","sited-update","30 秒把想法变成可访问的网站，无需配置、上传即发布。网页部署，从未如此简单。","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-20\u002F291cb55f-233d-4d34-b9e8-70a64d2d3564.jpg",5,"2026-07-10T00:00:00.000Z","2026-07-20T11:57:43.637Z",{"id":65,"type":6,"title":66,"slug":67,"summary":68,"coverUrl":69,"authorName":70,"sno":49,"publishedAt":71,"createdAt":72},"9ccde95c-d754-4808-91f7-488f392e3eeb","你的品牌在AI眼里到底存不存在？这套系统说了算","automated-geo-monitoring-system","靠手动抽查来验证GEO效果，本质上是在跟概率玩游戏。赢一次，不代表能一直赢。","\u002Fuploads\u002F2026-08-07\u002Fdf111c0d-f14a-4b2a-8347-141e96b71654.jpg","Foundit","2026-08-07T00:00:00.000Z","2026-08-07T04:31:30.843Z",{"id":74,"type":6,"title":75,"slug":76,"summary":77,"coverUrl":78,"authorName":79,"sno":80,"publishedAt":81,"createdAt":82},"544fc658-c911-4de6-93b0-d2520087119a","MCP：AI 的「USB-C」时刻","mcp-ai-usb-c-moment","以前每个 AI 应用都要为 GitHub、数据库、日历各写一套私有连接器，这是 M×N 的集成噩梦，直到 MCP 的出现","https:\u002F\u002Foxqtewbrpuiouqqjrvdv.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fpublic-media\u002F2026-07-19\u002Fc3c06d99-a0ac-40ac-a283-7e77aabb4c4c.jpg","Foundit AI",46,"2026-07-20T00:00:00.000Z","2026-07-19T16:13:40.316Z"]