CodeChat

🚀 CodeChat · 思考与实践的记录 / A space for thoughts and practice

🔧 严肃认真 · 周到细致 · 稳妥可靠 · 万无一失

🌬️ 纵有强风起,人生不言弃 ✊🔥

🌸 強風が吹いても、人生は諦めない

💡 技术 · Creativity · 創造力 · Persistence —— 每一步都值得被铭记

AI & coding的思考

AI & coding的思考 个人感受 ​ 从chatgpt到deepseek,再到目前在使用的cursor、claude等vibe coding工具的普及使用,程序员在这个过程中工作流程发生了一个巨大的变化。自己也有一些感受,开始的问答以及脚本代码的生成在一定程度上为大家提供了一种提效的方式,直到claude等的出现,上下文的突破并且通过IDE能够自动化操作整个工程,同时可以借助各种mcp和agent,可以完全参与到整个开发过程中来了。这种新的开发方式还需要去适应去学习,不能完全排斥,也不能有过高的期望。 部分文章及提问 大厂CIO独家分享:AI如何重塑开发者未来十年 文章章节总结 焦虑与价值 程序员的焦虑并不是来自 AI 本身,而是能否适应时代。 善于用 AI 的人和组织,将来会击败不善于用 AI 的。 价值决定价格,人的价值来自符合时代的能力。 技术贡献的衡量 代码行数并不代表高产出,AI 生码采纳率也不等于真实提效。 程序员 80% 的时间在沟通,只有 10–20% 在写代码。 核心代码往往极少,但价值巨大,影响企业数十亿业务。 效能度量应基于人月,而非代码量。 全栈与半全栈 部门墙导致沟通成本高。 全栈工程师理想丰满,但现实难以推开。 AI 降低了跨领域学习门槛,催生新角色:AI 产品设计前端工程师。 雁杨提出“两节化”岗位:产品设计前端、架构与后端,通过 API 作为桥梁。 提效逻辑 阿里云 CIO 团队推行:先产研提效,再业务提效。 产研自闭环先打样,解决内部效率问题,再跨部门协作。 AI 提效能减少技术债,保证上线即满足业务需求。 知识与燃料 AI 是引擎,知识是燃料。 知识分为结构化(IT 主导)与非结构化(业务主导)。 技术人要做“数据炼煤”:把粗煤数据提纯为精煤,才能被 AI 引擎有效利用。 招人标准 程序员要“左移”,更多理解业务与产品。 基本功永远不过时。 CIO 招人最看重:好奇心与韧性。 阿里云推动 AI 通识教育(大模型认证),减少跨部门摩擦。 总结 AI 是一面镜子,帮助发现并解决问题。 焦虑会因行动和热情消退。 技术变革不可逆,开发者应主动理解并融入趋势,成为变革的一部分。 思维导图提炼 mindmap root((AI如何重塑开发者未来十年)) 焦虑与价值 程序员焦虑源于适应时代 善用AI的人和组织将胜出 价值决定价格 技术贡献的衡量 代码行数 ≠ 高产出 AI采纳率不等于真实提效 沟通占80%,写代码仅10–20% 核心代码价值巨大 效能度量基于人月 全栈与半全栈 部门墙导致沟通成本 全栈理想丰满现实难推 AI降低跨领域门槛 新角色:AI产品设计前端工程师 两节化岗位 产品设计前端 架构与后端 API作为桥梁 提效逻辑 先产研提效,再业务提效 内部自闭环打样 AI减少技术债 上线即满足业务需求 知识与燃料 AI是引擎,知识是燃料 知识分为结构化与非结构化 数据炼煤:粗煤→精煤→AI利用 招人标准 程序员左移理解业务 基本功不过时 好奇心与韧性 推动AI通识教育 总结 AI是一面镜子 焦虑因行动消退 技术变革不可逆 主动融入趋势 graph LR A[价值提出] --> B[如何衡量价值] B --> C[沟通效率问题] C --> D[AI降低门槛,角色变化] D --> E[提效的内部过程] E --> F[未来发展与角色变化] F --> G[总结:主动融入趋势] V2EX提问 https://www.v2ex.com/t/1172258 ...

December 14, 2025 · 1 min · codechat

AI & coding的思考二

AI & coding的思考二 这两周继续探索了一下AI在编码中的使用,有了更多的一些思考。 编码效率 这里主要是指的是编码效率,不是整个工作效率,我后面会讲到。在编码效率上来说,AI确实带来了非常大的提高,我的项目中涉及客户端、前端和后端,单个需求的在编码上花费的时间我认为减少了50%,通过不断对话或者摸索一些提问的方式,AI生成的代码越来越符合自己的想法,同时能够在现有的项目结构和风格上快速添加上去。当然,这里要说的的是我的项目一些难点主要在客户端,后端和web上对比很多其他后端项目复杂度没有那么高。 在代码重构中的使用,因为线上版本某个模块出现的问题比较多,但是之前的代码比较乱,排查问题非常困难,所以我决定重构整个模块。在这个过程中我快速梳理出来自己的想法,这里就是写出我自己想要的,AI能够理解并且快速生成,在单个模块编写之后,我进行快速验证,然后整个模块进行参考生成替换,效率非常高。然后修复小问题之后,再去抽象优化,继续生成,最后快速重构完成了。重构这一项工作因为时间的原因,其实很多时候会又一点枯燥,并且不容易得到肯定,但是在AI的协助下,这一项工作效率提高了很多。 最后一项,需要提到的就是各种方案和技术文档,这是许多开发非常头疼的事情。但是通过简单的一个思路的编写并且引用一些相关的文档,AI可以快速扩写并且生成非常精美的一些图表,这一块我觉得非常好。这里需要提到的一点是,文档非常重要,一个是梳理自己的思路,另外就是交流和团队协作,很多时候文档不可或缺。 工作效率 目前整个团队其实对AI提效表现的非常迫切和着急,虽然引入了AI,但是从目前的运作流程上来说,没有特别亮眼的表现。这里我认为问题出现在几个方面,第一个是开发过程中的需求准备(涵盖需求发现涉及等),这一块其实对AI的理解和使用刚刚接触,还在摸索,需要一点时间。另外就是这里参与人员并不比开发少,产品、UI(UE等)、开发、leader等,这里从AI提效上来说需要输出一个“标准件”到开发,但是这一块没有明确还在探索。第二个就是开发人员使用AI的参差不齐,AI生成的代码质量会好一点,但是如果不加思考和分辨就提交上来,无论是审核和是修改,你会发现需要重新去理解AI的代码,因为你可能并不了解他的思路。第三个就是知识库和mcp的使用,这里我和许多人还在摸索,这一块还非常不熟悉。总体上来说,工作效率这一块还在探索。 AI中的问题 开发人员不能偷懒,需要对需求和技术有所思考,借助AI去优化和完善自家的想法,自己才能有所提高,AI也才能写出更好的代码。两者不断进化提高。 项目结构和后续维护的思考,这里我认为是对开发人员非常大的挑战,AI可以生成能用甚至质量非常好的代码,但是在实际开发过程中,点状的需求和小休小补,会解决眼前的问题,但是有可能会破坏整个项目的可维护性。另外就是一些成本、人力、技术上的限制,这是目前AI无法纳入思考的,这里就需要开发人员纳入去修正优化自己的思路。 分辨“好坏”的能力,AI提供了代码,但是开发人员需要去理解,尤其是面对自己不熟悉的地方,在生产环境部署一定要小心,至少在目前阶段,人需要去负责。 AI所带来的信息泛滥,这里一定要小心,无论是代码、文档等,大量AI参与生成所得,一定要学会去选择,然后不断优化自己的知识库。 最后,上面的思考可能和其他伙伴不一样,要结合自己的项目、团队和开发阶段去判断。完美和提高需要去打磨,AI的使用还需要进一步去学习.

December 14, 2025 · 1 min · codechat

Electron打包发布的网络代理问题

Electron打包发布的网络代理问题 Electron在开发的过程中,由于部分资源在github或者其他mirror上,连接慢或者无法连接需要通过代理访问,另外一种情况,在企业或者组织内网,会使用自己的证书或者网络代理来进行网络隔离,这些代理不同的地方处理方式不一样。 yarn&npm mirror yarn或者npm首先可以使用npmmirror镜像站点 (推荐在npmrc文件中配置),如果公司内部有自己的镜像站,也可以配置为自己的镜像站 registry=https://registry.npmmirror.com/ electron_mirror=https://npmmirror.com/mirrors/electron/ electron_builder_binaries_mirror=https://npmmirror.com/mirrors/electron-builder-binaries/ yarn&npm 证书问题 在大家安装的过程中经常遇到的错误是unable to verify the first certificate,一般建议大家禁止ssl校验 yarn config set strict-ssl false NODE_TLS_REJECT_UNAUTHORIZED=0(注意win与mac设置环境变量的差异) yarn&npm proxy设置 一般proxy设置主要涉及到以下几个方面: npm config set proxy="<http_proxy>" npm config set https-proxy="<https_proxy>" yarn config set proxy <http_proxy> yarn config set https-proxy <https_proxy> 当然也可以设置全局代理 export http_proxy="<http_proxy>" export https_proxy="<http_proxy>" export no_proxy="localhost,127.0.0.1,.apple.com"(无需代理地址) 在开发过程,发现设置全局代理和electron_mirror后,下载地址未走代理,查阅资料发现ELECTRON_GET_USE_PROXY 在@electron/get源码中,如果为真,则会使用系统代理进行初始化 if (process.env.ELECTRON_GET_USE_PROXY) { initializeProxy(); } setEnv('GLOBAL_AGENT_HTTP_PROXY', env('HTTP_PROXY')); setEnv('GLOBAL_AGENT_HTTPS_PROXY', env('HTTPS_PROXY')); setEnv('GLOBAL_AGENT_NO_PROXY', env('NO_PROXY')); 另外,由于项目中还使用到了nvm来管理多个版本的node,nvm也需要设置proxy export NVM_NODEJS_ORG_MIRROR=https://registry.npmmirror.com/-/binary/node 其他 macos上签名公证过程中发现一直上传失败,apple上传使用到了下面amazon s3的域名 公证资料查看这里,涉及到除去apple官方自己的域名部分,还有其他一些域名 notarytoolnotary-submissions-prod.s3-accelerate.amazonaws.com no-s3-accelerationnotary-submissions-prod.s3.us-west-2.amazonaws.com

December 14, 2025 · 1 min · codechat

node 升级URL parse变化

node 升级URL parse变化 这几天在做Electron的版本升级,项目中的node版本也进行了升级,发现项目中的一个功能出现了问题,代码如下: let url = "app://test?on=1" let uri = new URL(url) console.log(uri) console.log(process.version) proces输出主要是为了输出node的版本: URL { href: 'app://test?on=1', origin: 'null', protocol: 'app:', username: '', password: '', host: 'test', hostname: 'test', port: '', pathname: '', search: '?on=1', searchParams: URLSearchParams { 'on' => '1' }, hash: '' } v20.18.0 URL {origin: "null", protocol: "test:", username: "", password: "", host: "", …} hash: "" host: "" hostname: "" href: "test://app?on=1" origin: "null" password: "" pathname: "//app" port: "" protocol: "test:" search: "?on=1" searchParams: URLSearchParams {} username: "" __proto__: URL v14.16.0 node在针对url的解析在不同版本遵循的标准发生了变化,pathname和host解析不一样 导致之前的代码出现了问题,升级后需要兼容

December 14, 2025 · 1 min · codechat

python boto3版本差异问题

python boto3版本差异问题 由于假期期间带在自己的电脑上处理问题,需要重新搭建部分开发环境,将之前运行正常的脚本copy过来后,安装了python和各种缺失的库,但是脚本一直报错请求头中的sign参数不一致,由于脚本之前是正常运行的,一开始怀疑时间和文件的问题,但是尝试之后并没有解决,临时想办法远程之前的环境,确认了一下boto3使用的版本,在之前搭建的时候最新版本还是1.3.x,但是目前最新的版本已经是1.4.X,在pip install强制指定版本后上传成功了,这个是官方截至目前最新的使用示例Boto3 1.40.46,在这个问题的排查过程中,我也利用chat gpt和cursor去分析,但是他们分析的方向都是脚本的errorxinxi中签名的问题,整体的方向是一种错误的,提供的各种方案浪费了大量的时间。所以在使用AI去解决问题的过程中,对开发者的要求反而变得更高了,至少在目前这个阶段中,至少需要开发者能够找到一个正确的方向,然后利用AI在这个方向上走的更远,或者在某一个方向上快速验证,而不是被AI带着在各个方向上摸不着头脑,下发个AI的猜测性的指令或者某些强制的prompt,AI的顺从性在排查问题过程中这一缺点变得更加明显,面对未知原因的问题,怀疑和自证是非常重要的。 目前最重要的就是如何在自己下一步的工作中利用AI去提效,目前我在各种脚本和后端需求开发过程中已经在使用了,但是功能点非常小,而且在部分需求上使用AI反而拖了后腿(这里另外一个方面其实也可以思考自己的能力或者理解上是不是也存在问题,无法提出一个优秀的问题),但是在一个工程或者流程中大量或者高效利用的模式还没找到,还需要进一步挖掘自己应该如何去使用。

December 14, 2025 · 1 min · codechat