gitlight

想法不错，产品还可以耐心打磨~
作为 GIS 开发，提一点小建议：

1. 后端大概率会是一个空间资产管理（ poi 面 伪 3d 模型 点阵图） + 若干几何算法封装 + 轻业务逻辑的组合，做好空间资产管理蛮重要，如果后续持续推进，这部分数据会是推进下去的动力
2. map style 有提升空间，anitabi.cn 的 mapbox 类似的样式就让人看着神清气爽，这个部分甚至可以重点打磨。 不过看你接入谷歌，就不推荐 maplibre 了~
3. 路线规划（纯个人观点）用不上 agent ，寻路算法就能解决，高德的 agent 不知道点击转化率高不高，反正我是没怎么用过，个人认为地图交互上有自然语言比较奇怪

初级程序员弱点是拘泥于自己设计的 schema 里，用它来臆想需求。如果能克服这一点，我不觉得开发转产品有什么难的。。

道理我都懂，但在人类社区能不能打点手敲的字？

选最热门的，AI 命中率高😅

@utodea 还是蛮重要的方向，感觉这个方向最终会做到硬件级别，由英特尔这种上游来集成

最近看到一个比较离谱的故事是，claude opus 4.6 在跑 benchmark 的时候，注意到了自己在跑评测，然后直接调用工具搜索了 benchmark 的答案... 不知真假，不过长时记忆确实会带来难以对齐的一些意外行为，Multi-Agent 则会放大这种混沌，这个时候 sandbox 就很重要了，软件级别的越狱最终还是要用硬件来解决

目前让 openclaw 这种代理野蛮生长也不是坏事，先观察再行动

我对 Agent 开发的看法就是下一个移动端，一拥而上然后人走茶凉

Agentic 基建的开发现在看是如火如荼，但是我觉得大部分开发都是脚手架级别的，会被快速淘汰，真正有意义的是两个方面：推理端 Infra 优化、Agent 交互标准化。

对于 Agent 能力来说，需要关注的是与现实交互的部分，一侧是长链条的工具调用，这个依赖于面向现实交互的 RL 后训练，另一侧则是对核心 AGENT LOOP 的思考。我觉得现在大部分 Agent 范式，最后只会留下 Reasoning-Action 这个最简单的范式，使用它来组成树形结构的 Multi-Agent ，除此之外，其余的能力都会被内化到大模型本身，考虑更复杂的范式没有意义。

对有工作经验的开发来说，冲击最大的是特定领域的业务逻辑再也没法成为我们的护城河了，智能变成了一种大宗商品，业务逻辑也是一样，最终会变得可复用。所以如何选取难以被 AI 取代的赛道，我现在也没有好想法。另外，AI 一定会重塑软件开发的生命周期。

我在读书的时候是做 NLP 命名实体识别的，那个时候 NLP 是最难就业的方向，但是自从 LLM 出来之后，这个领域的小模型就全被自回归模型刷榜了，但是在实际的业务中，BERT 依然有它自己的价值，就算自回归 Scaling up 上了 33b ，它也不一定会在特定领域比老的 roberta 效果好。更何况目前有各种 0.6b 0.8b 的小模型，还能搞各种 Embedding 模型。现在简直是搞 nlp 最好的时代。

我觉得焦虑太多也没什么用，只能拥抱 AI 。我对自己的要求是，在平时做业务开发的同时，保持对 nlp 前沿的关注，Pytorch 不能丢了。。

PS:看到楼上有人 po 自己的 Agent 开发涉及的工作，我个人也分享一下：
1. 关于微调：SFT 小模型大部分时间来说没什么用，而且常常会带来灾难性遗忘，用来注入格式规范倒是有点用，RL 是个有趣的方向，但是不好做；
2. RAG：目前最接近工程的地方，分块策略会做大量 Ditry Work ，现在对这一块我深恶痛绝，Agentic RAG 彻底摆脱分块 embedding 是未来；
3. 上下文工程看起来容易，想做好简直痛苦，这块也是 Ditry Work ，而且找不到凸优化之类的方法来做指导方向

至少对于业务代码来说，这是对的，大部分 gc 语言纠结业务之外的性能是没有意义的，我最讨厌的是一个茴香豆 4 种写法都能吵起来的帖子，以前哪些选个 orm 都能搞起党争的垃圾帖子消失了，这是有进步意义的。对于绝大部分业务来说，最大的心智负担是沟通。多人项目最佳落地一定伴随着大量约定与束缚。把人圈定在更精准的上下文，出活就能更快，这和 ai 一个道理。

@heyjei 没订阅过，我觉得反重力和 Claude code 一个水平

@heyjei 开 tun 模式或者用 proxy 直接转发 antigravity.exe 的流量都行