我对ai的依赖程度是离开它我就会死的程度

现在每年回家，都是坐高铁回家，而且我们那还通了城际铁路，回老家还是很方便，虽然城际铁路那一站离农村老家有点远，不过还好，有接驳的公交小巴士，坐十站左右就到了，在步行十多分钟就可以到家。不过每次回家，父亲或哥哥，都会开着哥哥的小车到车站接我，总会看到站外他们熟悉的身影。到站时，父亲就会抢过我的拉杆箱，轮子在水泥地上磕出咯噔咯噔的响，他却走得比我还快，好像很想快点把我接回家。三十的晚上，父亲喝了口白酒说："现在出门不远就有一个文化广场，晚上全是跳广场舞的，热闹的很。“，确实，我还去逛了逛，在广场上晒大太阳。这些年，老家确实发生了很大变化。假期最后一天，父亲把腊肉用麻绳捆成小捆，把年前蒸的...

当习惯了校园的生态系统，突然被移植到全新的土壤和气候时，身体和心理上都很“水土不服”。等待“被布置作业”习惯了老师安排、划重点、布置作业。到了职场，也习惯性的等待着领导来告诉自己做什么、怎么做。导致手头工作完成就开始“摸鱼”等待下一个指令；遇到问题，就是等着领导给答案。你的作用不是“听话”，而是为“解决问题”付的。接到任务，不仅要问清楚怎么做，更要试着理解这件事情的目的，这样你才能知道你能做些什么。完成任务之后尽量主动闭环。“没有功劳也有苦劳”职场是价值交换，最主要的是过程。不要向领导展示自己有多忙、加了多少班，却拿不出实际的工作成果。一旦结果不好，就用“我已经很努力了”来为自己开脱。喜欢向领导展示自己有多忙、加了多少班，却拿不出实际的工作成果。一旦结果不好，就用“我已经很努力了”来为自己开脱。别把求助当“作弊”求助在职场中不是示弱，是一种高效的协作方式。带着你思考过的问题去请教，是在整合资源，节省团队的时间。问过的问题要自己做个总结，总向别人求助同个问题，脾气不好的同事不会惯着你的。把批评当“差评”做事畏手畏脚，不敢承担责任，被指出问题时候辩解、情绪低落、自我怀疑，你是否也存在这样的问题？职场中的反馈，绝大多数是对“事”不对“人”。领导指出方案的问题，是在说这个方案可以更好，而不是在否定你这个人。把每一个错误和批评，都看作是发现盲区、获得免费指导的机会。脸皮厚一点，心态稳一点。可以这样想：“太好了，又发现了一个可以改进的地方，我又能进步了。”

现在看到裁员消息，已经见怪不怪了。但是这次的消息，真的惊到我了！以往裁员都是公司业务调整、盈利不及预期，但是你见过业务发展不错要裁员的吗？当看到 Jack Dorsey 的 Block 裁员 4000 人，且老杰克云淡风轻地说出那句 “绝大多数公司最终都会走到这一步” 时，我手里的咖啡差点洒了。这不是新闻，这是回旋镖，扎扎实实地扎在了咱们每一个程序员的胸口。杰克·多西没撒谎，公司确实在执行“强制 GC”以前我总觉得只要代码写得稳、系统不宕机，饭碗就稳。但老杰克那句话点破了资本的底层逻辑：公司也是一个程序，它的运行是有周期的。 扩张期像是在疯狂申请内存（招人），等到了收缩期或者效率瓶颈期，为了不...

我本科一直做 Web 相关开发，技术栈主要是 React / Node / TypeScript / Python。一开始接触大模型，其实和很多人一样：写 prompt、接 API、做点 demo。但很快我就发现，如果只是“调 API + 写 prompt”，其实很难真正做出复杂的 AI 应用。这篇文章主要分享一下：从前端工程师转向 Agent 开发，我的一些经验和踩过的坑。一、很多人刚接触大模型时，会觉得 AI 应用开发就是：写 Prompt调 OpenAI API输出结果但实际上，如果要做复杂应用，真正的问题通常是：上下文管理（Context Engineering）工具调用（Tool Use）任务轨迹设计（Agent Trajectory）状态管理（Memory / State）成本与延迟控制这些其实更接近 系统工程问题，而不仅仅是 prompt 的问题。二、前端背景有几个优势1 状态管理经验前端：state → viewagent：state → reasoning → action本质类似。2 工程能力前端工程师通常很熟悉：模块化API 设计工程结构渐进式披露（很重要）这些在 Agent 框架设计里很重要。3.相关技术栈openclaw，cluade code和opencode均使用typescript作为其主要开发语言，ts在agent项目里的使用比重很高。三、Agent 的核心其实是“轨迹”很多人以为：prompt → answer但 code agent 实际是：thought→ tool call→ observation→ thought→ tool call→ ...所以关键问题变成：如何设计agent loop如何设计 tool如何设计 observation如何管理上下文四、最近面试和做项目的过程中，我也有一些反思：1 多复盘，而不仅仅是做项目很多时候不是做得不够多，而是复盘不够。2 定量大于定性不要只说“优化了性能”，而是尽量给出指标：- latency ↓- token cost ↓- success rate ↑3 多方案 trade-off工程问题通常没有唯一答案，关键是：- 方案 A- 方案 B- 为什么选 B4 技术要服务业务不仅要看技术指标，还要看：- 用户体验- 成本- 整体业务效果5 尽量 close ticket，而不是一直做 demoAI 领域很容易陷入“做很多酷的 demo”但真正的工程能力是：解决具体问题并落地。五、如果你也是 Web 开发背景，其实完全不用焦虑“AI 门槛很高”。很多 AI 应用开发，本质上还是工程问题：系统设计状态管理工程架构只是多了一个新的组件：LLM。如果你已经有扎实的工程基础，再补充一些：LLM 基础Agent 设计Context Engineering其实是可以很自然地转过来的。