hongjic93

技术上最大的难点恰巧是 op 觉得很当然的使用者必须明白自己的需求是什么。需求的精准表达需要的不仅仅是使用维度的 context ，引入生产设计领域的专业 context 更重要。这是为什么所有的需求都需要使用者和提供方反复讨论多轮（甚至都仍然有 gap ），从一开始客户的一句话变成数万字的需求/工程文档。


技术之外：
我以前和一些不懂软件开发的朋友聊过这个话题，他们不认为自己以后会成为“程序员“，他们还是会找”程序员“开发软件，或者 AI 。他们认为开发软件不是自己的事，即使这件事变得再简单不过。

所以我认为消费者永远是消费者，生产者永远是生产者。ai 时代会诞生一批 ai 消费者和 ai 生产者，但不会让消费者和生产者产生角色整合。

基于 vscode 没问题，因为真的没必要重复造轮子。。 但 cursor 也是有重要创新的，可以看下他们的 shadow workspace blog post.。 本质上对每个 cursor 项目，人类用一个 workspace ，ai 会在背后 shadow 一个 copy on write workspace 。 还是挺有意思的，感觉是很多 ai agent use computer 都需要的一种设计。

goplugin （同一个进程，动态链接库），sidecar （不同进程，ipc ），wasm （进程内部 sandbox ） 。 第一个坑很多，ipc 很麻烦，wasm 最理想，但不成熟（ golang 已经支持 wasi 编译）

AI （文本加视觉模型）+ 浏览器自动化工具。

工具比如 browserbase： https://github.com/browserbase/stagehand
有用是有用，但可靠度要看不同厂商在对自家内容平台保护的力度。道高一尺魔高一丈

支持一个。不过想请问一下这种类型的 app 一般怎么让用户确信他是安全的？

类似 tailscale 的工具应该基本覆盖了 OP 的设想。

本地模型意义很大，你可以给他所有本地传感器和资料的访问权限，不能理解本地模型没有意义的说法。以后不只是厂商 token 会变便宜，模型部署门槛和消费算力成本一定降低得更快，大模型和小模型的智能差距缩短得会很快。

mcp 和以前的 function calling 有什么本质上的不同吗？怎么理解呢？

@xiangbohua 同意，无论哪里永远都会有这个问题，只是 ai 现在还是烧钱时刻，天下没有免费的午餐。

反过来，我觉得以后最好的方案可能会回归到卖硬件来收回软件成本。用户付费买设备，设备可多用途所以也不算亏，不依赖广告收入，本地化还能解决 ai 隐私问题。