文章指出当前网络软件多为静态，主要满足大众需求，但存在大量未被满足的长尾需求。LLM辅助编程的出现，让用户能更轻松地开发满足自身特定需求的功能，从而填补这些空白。

好的，这是根据您的要求，对原文主要内容进行的中文重述，已保留关键细节并删减了与主题无关的内容。

标题：LLM时代下的可扩展软件

核心观点： 当前大多数网络软件是静态的，开发者只能满足大多数用户的通用需求，而无法顾及每个用户的个性化“长尾”需求。大型语言模型（LLM）的出现，使得为个人或小团队构建定制化软件成为可能，这催生了“小软件”的机遇。作者认为，网络软件的下一个机会在于构建“可扩展软件”：即提供一个稳固、可靠的核心，并允许用户通过LLM安全地扩展其功能。

LLM原生软件与可扩展性： * 现状： 传统软件添加新功能会复杂化产品，对不需要该功能的用户造成困扰。LLM辅助编程让用户有能力为自己构建“一人软件”。 * 新范式： 以Pi为代表的“LLM原生软件”提供了一个经过实战检验的核心，用户只需通过自然语言请求，就能扩展其功能。用户甚至可以将自己的定制分享给他人。 * 核心洞察： 用户突然拥有了“将语言变成代码”的能力，但大多数现有软件无法利用这一点。未来的软件应遵循“自我扩展”模式。

可扩展软件的应用场景： 1. AI代理： 与其不断为核心添加新功能，不如提供稳定的钩子（如工具、命令、事件），让LLM将用户请求转化为小型扩展并即时加载。这避免了核心臃肿，但当前本地运行的代理存在安全性和使用门槛问题。 2. 企业内部平台： 员工需要查询、关联、分析数据。与其让员工各自“氛围编码”并部署到PaaS，不如提供一个安全的平台。该平台由内部团队管理数据访问和合规性，员工可以在安全边界内构建自己的自动化或自定义视图。 3. 支持平台： 允许支持人员创建扩展，在工单界面中直接展示来自不同系统的数据，或一键执行“重置配额”等常见操作，并可与团队共享。 4. 可观测性平台： 允许用户注入自定义逻辑，例如：在数据摄入时进行转换、让告警触发自定义脚本、将日志中的ID转化为指向其他平台的链接，或实验自己的可视化方案。

实现可扩展网络软件的挑战： * 安全问题： 执行用户自定义代码存在巨大风险，包括：服务宕机、数据泄露、拒绝服务攻击、加密货币挖矿等。 * 历史案例： Salesforce自2007年起就通过其Apex语言实现了多租户的可编程平台，允许用户在平台上安全地运行自定义逻辑（如自定义API端点、定时任务）。这为现代可扩展软件提供了参考。

构建可扩展软件所需的技术原语： 1. 经济性： 代码不执行时成本趋近于零，每次执行成本极低。 2. 快速冷启动： 启动时间应在毫秒级，以支持实时请求。 3. 资源限制： 必须能对CPU、内存、网络请求、日志量等所有资源进行限制。 4. 强隔离性： 用户代码的崩溃或恶意行为不能影响其他用户，包括防范Spectre等侧信道攻击。 5. 安全操作： 用户代码需要能安全地执行操作。最佳实践是采用“能力模型”（Object-Capability Model），即只向不可信代码传递执行特定操作的引用（如getApprovedEmail()），而不是暴露API密钥或原始fetch。这比使用代理进行权限过滤更安全、更易于推理。

可行的技术方案： * 解释器： 如Lua、QuickJS，或自建语言（如Salesforce的Apex）。 * V8隔离实例： 利用V8引擎的隔离能力，如Cloudflare Workers、isolated-vm等。 * 微型虚拟机： 如Firecracker，提供强隔离性，但开销较大，适合需要完整POSIX环境或大量CPU/RAM的场景。 * WASM + WASI： WebAssembly从零开始，无内置I/O能力，安全性高。WASI定义了宿主向WASM代码传递能力的标准接口。

Cloudflare Dynamic Workers 的契合度： 作者认为Cloudflare的Dynamic Workers是目前最接近生产就绪的框架，因为它提供了构建可扩展网络软件所需的多个关键组件： * 可观测性： 内置OpenTelemetry追踪和日志控制。 * 多租户数据存储： 可为每个用户提供独立的SQLite数据库或对象存储。 * 持久化执行： 支持需要数分钟或数天完成的工作流。 * 源代码管理： 内置版本控制功能。 * 托管LLM： 用户可在扩展中直接调用LLM。 * 自托管JS工具链： 可在同一环境中编译和测试用户代码。

结论： 将应用转变为平台非常困难，需要大量的前期设计和长期支持。但平台能让用户发挥创造力，做出开发者未曾想到的事情。尽管困难，但构建可扩展平台是值得的。

根据评论内容，总结主要观点如下：

观点一：AI将重塑软件开发模式，使个人快速构建定制化应用成为可能 - 支持者认为，AI（如LLM）能快速生成满足个人需求的“软件为一人”应用，绕过企业软件的复杂性。例如，评论3作者用30分钟创建了自己的小型软件，并认为其效果优于现有臃肿的选项：“it works really well, and I don't feel like, 'Hey, the options out there are better.'” - 评论5以2002年用30分钟编写MP3播放器的经历类比，说明即使没有LLM，个人也能快速构建简单工具，但LLM降低了门槛：“I'm pretty certain, had LLMs not existed, that I can make an application finder... in about 30m.”

观点二：未来软件将走向可扩展、可定制的平台，但存在安全与分发挑战 - 评论1预测，GitHub等工具的未来是“a platform for manual testing”，AI处理用户请求并生成变更，程序员负责验证和填补漏洞：“The bulk of development work going forward is manual verification that the LLM understood the user request correctly.” - 评论8和9强调可扩展软件（如插件系统）的潜力，但指出安全限制（如浏览器沙箱、权限管理）是难点。评论9提到：“CSP only restricts which origins the code can reach, not the method or the path... this is hard especially when our target users are non/less-technical.” - 评论10质疑“软件为一人”为何需要互联网分发，认为本地可扩展软件更合理：“Why not just work on designing pluggable local software that isn't so 'professional'?”

观点三：对AI主导软件开发的未来持怀疑态度 - 评论6认为，普通用户更倾向于可靠、功能完整的软件，而非高度个性化工具：“Normal end users want reliable software that does what they want it to do.” 并指出AI替代的是“a person working for you”，而非传统工具。 - 评论2提出另一种未来：客户可能提供LLM生成的程序或上下文作为需求，开发者据此构建实际软件，LLM仅作为辅助：“Developers will refer to the program... and the developer will build the actual program with or without the help from LLMs.”

观点四：技术实现需关注安全与数据控制 - 评论11和12强调能力组合（capabilities）和沙箱执行的重要性。评论11提出：“The cool part is a move to capabilities composed in code brings back everything great about software itself: composability, encapsulation, type systems.” - 评论12指出，即使有沙箱，数据访问控制逻辑的缺陷仍可能导致安全问题：“the security of the sandbox doesn't matter if they expose some external endpoints and if the access control logic which guards data is flawed.”

总结：评论围绕AI在软件开发中的角色展开，支持者认为AI能赋能个人快速构建定制应用，推动可扩展平台发展；怀疑者则关注普通用户的实际需求、安全挑战及AI的辅助定位。技术实现上，沙箱执行、权限管理和数据控制是核心议题。