标签 AI 编程 下的文章

阮一峰的周刊今日的 title 讲的是 google 程序员 Steve Yegge 最新的文章 https://steve-yegge.medium.com/welcome-to-gas-town-4f25ee16dd04 中 对 AI 的看法
他说 AI 编程有 8 级
第 1 级,还没有接触到 AI 编程,你的 IDE 还是正常的样子

第 2 级,你在 IDE 装了 AI 插件,开启了侧边栏,AI 时不时提出代码建议,问你是否接受( Yes or No )。

第 3 级,你开始信任 AI 编程,进入了 YOLO 模式("你只活一次"模式,You Only Live Once )。为了节省时间精力,你不再逐条确认 AI 的建议,只要是 AI 生成出来的东西,你就一路按 Yes ,统统接受。

第 4 级,AI 占据的屏幕宽度越来越大,手工编辑的代码区仅用于比对代码差异。

第 5 级,你索性不要代码区了,改用命令行(比如 Claude Code ),所有的屏幕宽度都留给了 AI 。你现在不看 AI 的生成结果了,只看它的完成进度。

第 6 级,你觉得只用一个 AI 太慢,于是打开 3 到 5 个窗口,同时进行 AI 编程,加快速度。

第 7 级,同时打开的 AI 编程窗口到了 10 个以上,已经是你手工管理的极限了。

第 8 级,你开始使用 AI 任务编排器,让计算机管理并行的多个 AI 编程。

我现在应该是 LEVEL 6 ,claude code + 某很便宜的国产模型,使用强度没那么大 但是之前也用过 vibe-kanban 之类的开源工具 感觉体验不太好 ,总会报错,还不如多窗口。 但是代码类的 ai 生成后 我还是会自己 review 并提交

v 站的大佬们都到哪一个级别了 具体使用方式是什么呢

今天被一张《IT 开发工作可能要完全重组》的图片刷屏,图片中的观点是:传统的「产品-设计-前端/后端」模式在 AI 时代将被变革。

很多人会觉得“前端没有实际的必要了”是管理者自嗨,但就我个人的见闻而言,这可能真的是未来趋势。

基于 AI 的一专多能“超级个体”模式已经在很多公司铺展开,未来不久程序员大概率会不分前后、只剩全栈。

之所以敢这么笃定,是因为今年我亲身经历了这个变化。

简单聊聊我的工作变化

今年我的工作 80% 都是 AI 相关,工作内容上有三个比较大的转变:

技能层面:从“纯前端技术”转向“产品设计+AI内容生产+代码实现”的复合能力(例如:结合自身的冥想经历,提出并开发上线冥想呼吸练习功能)。
协作层面:从“与产品/后端对接”转向“与AI协同+跨部门整合”(例如:直接参与产品需求设计,用 AI 快速做 demo、上线验证方案可行性)。
成果层面:从“交付代码”转向“交付「产品+技术」解决方案”(例如:用 AI 生成热点资讯)。

工作时间分配上,也从之前的「大部分时间手写代码」变成了:

20% 的时间:手写代码(一般是改 bug)
30% 的时间:指挥 AI 写代码、review、accept/undo、cmmit & push
30% 的时间:优化提示词的效果
20% 的时间:和 AI 碰撞点子和改进方案

在我做的这些项目里,正如文章开头的图片所说,完全没有前后端岗位的概念,基本上都是和业务方沟通完需求、确定好方案,就开发、上线,甚至有的需求我自己定方案(在 AI 的加持下)。

插播一则机-会

技术大厂,前端-后端-测试,全国均有机-会,感兴趣可以试试。待遇和稳定性都还不错~

前端是不是真的没有实际的必要了

那么问题来了,前端/后端以后是不是就不需要这么多人,大家要失业了?

我的看法是:程序员这个岗位的确会变少,但适合我们的新机会也随之诞生了。

随着大模型的编程能力提升和配套设施完善,代码开发的 AI 化必定会发展到 80% 甚至 90%(至少还需要 10~20% 的人把关)。

如果只盯着程序员的「把需求文档实现为代码」这个职能,我们的机会是越来越少的。

但如果着眼于使用 AI 进行业务流程改造和内容生产,机会会越来越多。

最近两年开始,很多公司开始招聘名为「AI 工程师」的岗位,他们的工作内容就是业务优化和 AIGC。这个岗位招的人呈两极分化:要么是年轻的高学历应届生、要么是经验丰富的资深开发者。

招高学历应届生是因为他们具备创新和挑战精神;而招资深开发者转型 AI 应用,是因为他们有业务经验、全栈能力更强。

我今年的岗位角色就是 AI 工程师,在带着这种视角工作时,会发现有太多可以做的,以前凭感觉定的都可以用 AI 重做一遍,AI 工程师目前还远远不够。

想想我们的产品里有多少文案是写死的?有多少数据是无人问津的?有多少策略是拍脑袋定的?这些都是 AI 工程师可以改造优化的点。

总结

忍不住多写了几句,一看表这么晚了,年纪大了不能熬夜,总结一下结束此文。

技术变革就是会让生产效率提升,让工具性的岗位变少(程序员说白了就是把人的语言翻译为机器语言),但也会催生出新的岗位,我们要向前看。

从感性上我们是不愿意接受的,怎么革命偏偏革到了我们头上?我的房贷还没还完呢,以后可怎么办呢?

别慌,就我今年的经验来看,这一波 AI 技术革命,作为软件开发的我们有先发优势,只要稍加学习,再加上一些业务思考,很容易就可以转型到 AI 工程师。

至于如何转型到 AI 工程师,容我结合今年的工作&学习经验梳理下,也欢迎感兴趣的朋友留言讨论你们的看法。

滚滚长江东逝水,乘风安逸逆风衰,晚安朋友。

——转载自:张拭心

最近 15 人小组实践 vibe coding 遇到了一系列问题。整的我们连续加班了 1 个月。

项目背景:
公司里的核心项目。涉及资金流企业级复杂架构,对系统的稳定性和高可用性要求极其严苛。
这个项目是专门为大促(比如双 11 )这种极端高并发流量设计的,里面充满复杂的业务逻辑,比如多层级的数据核对、消息补偿机制和各种应急预案。技术路线上使用公司自研框架上从 0 到 1 开发。
而且压力大的是,它是个倒排期项目,上线时间给定死了,一秒都不能拖。

准备阶段:
这次开始前我们内部讨论了很久,决定采用 SDD (规范驱动开发) 模式,即由规范和文档驱动 AI 进行架构设计、系统开发以及单测和集测的编写。
出于数据安全的考虑,团队申请了一个全新的项目仓库。明确要求 AI 不能读取公司既有的私有代码库,以规避潜在的合规风险。
由于 AI 缺乏对公司内部定制或自研框架的了解,我们手动编写了大量示例代码和 Todo 供 AI 学习。
团队预先定义了多个 Agent (智能体),并设计了详细的 Workflow (工作流),试图通过流程化来约束 AI 的发散行为。

惊喜的开始:

• 详尽且专业的架构文档:AI 产出的架构设计文档看起来非常完善,甚至比人类写的还要好得多。人类写文档时往往会基于“常识”而忽略一些细节或内部约定,但 AI 会写得非常详尽,不遗漏细节。
• 惊人的开发速度: 在纯开发阶段,AI 展示了极高的效率。内部估算,如果是由人类工程师完成该项目的纯开发工作,大约需要 15 到 20 人日,而 AI 仅用了 3 天时间 就完成了所有的代码编写。
• 高质量的代码注释与异常处理: 我们平时为了追求开发速度,有可能对注释和异常处理的相对简单,但 AI 编写的代码在注释质量和异常处理机制方面比人类工程师开发出来的要好很多。
• 清晰的设计与逻辑分层:AI 在接收到相关知识后,能够定义出非常清晰的类图、方法、依赖关系和分层结构。它会先进行详细的设计,明确每个类的职责,初步看过去代码质量非常不错。
• 代码初期的易读性:AI 初步生成的代码逻辑相对直接(偏“面条式”代码),没有过度使用复杂的架构模式或抽象,这使得人类在第一眼看过去时觉得逻辑非常清晰且好理解。

不过这样的蜜月期,并没有维持多久,很快我们开始遇到各类问题,加班也多了起来。

遇到的问题:

1. 技术与代码质量问题
• 逻辑伪造与“将错就错”:AI 在面对缺失的知识、错误的接口文档或注释时,会伪造逻辑或猜测( Mock )返回格式。遵循“垃圾进,垃圾出”( GIGO )原则,如果输入信息有误,AI 的产出必然也是错误的。
• 错误传播与测试盲区: 如果 AI 基于错误的架构分析生成代码,它也会基于同样的错误逻辑设计测试用例,导致单测和集测无法发现逻辑漏洞。
• 产生“屎山代码”: 虽然 AI 初步生成的代码看似整洁,但在经过人工点对点的调试修复问题后,代码会逐渐演变成难以维护的屎山代码,。
• 缺乏企业内部知识: 由于数据安全限制,AI 无法读取既有的私有代码库,且对企业内部定制或自研的框架缺乏了解,导致其难以写出符合要求的代码。
• 不符合开发规范:AI 编写的代码往往不符合团队内部的开发规范或习惯(如事务处理方式),导致人类工程师在 CR (代码评审)或维护时感到非常困难。

2. 架构与设计层面的局限
• 输出不稳定与概率推断: 基于 Transformer 架构的 AI 本质上是概率推断模型,同样的输入和提示词产生的输出是不稳定的。我们为了研究针对本项目最佳的 AI 沟通方式,不断的测试修改各种提示词,花费了不少时间。
• 上下文限制与“遗忘”:AI 的上下文处理能力有限,在解决具体问题时可能会忘记之前的全局设计,导致代码复用性差,甚至在同一项目中针对相同问题重复编写不同的代码。
• “只见树木不见森林”:AI 容易陷入局部逻辑,忽略全局影响,例如在修改代码逻辑后忘记更新注释或相关的单元测试。
• 文档过度冗长:AI 喜欢编写极其详尽、甚至带有重复内容的长文档,这增加了人类阅读和理解的成本,往往 AI 5 分钟输出的内容,我们要花 1 个小时去理解。

3. 工作流程与效率悖论
• 工作强度反而增加: 使用 AI 后,程序员的工作时长变得更长、更累,甚至需要工作到凌晨,这与“AI 减负”的初衷相悖。
• 由于过度约束导致的“犯傻”: 为了约束 AI ,开发人员会定义越来越多的 Agent 和复杂的 Workflow ,但约束过多会导致 AI 出现“过敏”或变得笨拙,丧失了发散性思维的能力。
• Token 消耗巨大: 复杂的 Workflow 和长指令会导致 Token 消耗量激增(每天消耗上亿 Token ),导致成本异常昂贵。
• 陷入“面多加水”的死循环: 当 AI 做不好时,人类倾向于增加更多 Agent 或约束,这使得系统越来越复杂,最终效果反而变差。

4. 心理压力与管理挑战
• 认知负荷与上下文切换: 领导层可能误认为 AI 能大幅提升生产力,从而给程序员安排更多并发项目,导致程序员需要在多个 AI 窗口和项目背景间频繁切换,造成脑力枯竭,。
• 巨大的“不安全感”:AI 的自评分往往虚高(比如 AI 设计的架构或算法,我们让 AI 给自己打分结果他给自己打 98 分),但人类很难一眼看出其逻辑中的隐患。由于不理解 AI 某些设计的意图,人类工程师会产生强烈的不安全感和心理压力,。
• 信息爆炸:AI 产出的海量文档和代码需要人工进行大量审查( Review ),这一过程极其消耗精力。


后续反思
1. 明确 AI 的适用场景:
◦ 推荐场景: 编写一次性脚本、处理数据报表、编写复杂的 SQL 、整理文档、画图、辅助理解不熟悉的既有代码、查 Bug 、以及编写基础的单元测试和集成测试代码。
◦ 限制场景: 涉及核心业务逻辑、复杂资金流、高可用架构设计时,必须由人类主导。
2. 坚持“人机协作”而非“全权委托”:
◦ 建议通过 Web Coding 的方式,让 AI 按照人类提供的模板类和示例代码进行学习和约束。
◦ 核心逻辑必须按照团队的开发规范和习惯进行重写,以确保代码的可维护性和安全性。

利益相关声明:作者与文中产品有直接的利益相关(开发者、自家产品等)

Matrix 首页推荐 

Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 

文章代表作者个人观点,少数派仅对标题和排版略作修改。


AI 辅助创作声明:

本文由 Gemini 生成题纲,我完成内容创作,文章由 Gemini 后期润色。个人文笔不好,如对 AI 生成内容敏感还请见谅!


引言:原生党的「网速焦虑」与「毛坯房」

正在使用 Pixel 或类原生系统的朋友,对「毛坯房」这个调侃应该也并不陌生。虽然我们享受着最纯粹的 Android 体验,但总有一些本地化功能的缺失让人抓狂,「实时网速显示」就是其中之一。

在国内复杂的网络环境下,网速显示对我而言几乎是刚需。但尴尬的是 Google 似乎从未打算在系统层面支持这一功能。于是我们不得不转向 Google Play 商店寻找第三方解决方案。然而当我翻遍了市场上的同类应用,如 NetSpeed Indicator、Internet Speed Meter 等,却发现这些「老牌应用」在 2026 年的今天体验依然难以令人满意:它们大多有着过时的 UI 设计,许多 App 的界面还停留在 Android 4.4 或初代 Material Design 时期,放在当下的 Android 系统中总会显得格格不入;实际网速显示效果也一般,要么是状态栏上那个看不清数字和单位的小图标,要么是拖着「正在其他应用上层显示」膏药的悬浮窗;另外功能臃肿也是个问题,我只想要一个网速显示,它们却往往附赠了流量统计、详单分析等一堆我不需要的功能。

更致命的是,它们都有一个共同的痛点:开启代理工具时网速统计严重虚高。Pixel 用户应该遇到过这种情况,明明下载速度只有 5MB/s,网速悬浮窗却显示 10MB/s。

为什么这些工具的网速总是不准?

简单来说,这是 Android 旧版统计机制的「锅」。 传统的网速 App 通常直接读取系统的总流量接口,开启代理工具后,数据包首先通过物理网卡(如 wlan0)进入被统计一次,随后数据被解包并转发到代理工具的虚拟接口(如 tun0),这里又会被统计一次。

大多数老牌 App 只是简单地将所有接口流量相加,导致显示速度往往是实际速度的 2 倍。

好在最近 AI 编程确实火热,既然找不到完美的替代品,我萌生了一个想法:为什么不让 AI 帮我写一个专门适配 Pixel 的网速 App 呢?

于是 Pixel Meter 诞生了。

Pixel Meter 到底好在哪?

作为一款以解决个人需求为出发点的 App,Pixel Meter 主要解决了两个核心问题。

精准的流量统计(告别虚高)

Pixel Meter 摒弃了过时的全局统计方案,转而利用 Android S (API 31) 引入的新 API TrafficStats.getRxBytes(ifaceName)

这个 API 允许 App 精确获取指定网络接口的流量数据,通过内置的网卡白名单与黑名单机制,Pixel Meter 能智能过滤掉代理工具虚拟接口的重复数据。最重要的是,实现这一功能不需要 Root 也不需要 Shizuku 权限,做到了既高效又精准。

可能是目前最优雅的展示方式

实时活动通知(Live Update Notification)是我认为 Pixel Meter 最大的撒手锏,在 Android 16 及部分支持该特性的高版本系统中,实时活动通知相比于传统状态栏图标,不会有显示空间受限、可读性差等问题,允许我们灵活展示更丰富的内容。

不妨看个对比:

传统方案:拥挤的状态栏,数字和单位难以看清

Pixel Meter 则利用通知区域的实时更新特性,虽然有字符限制( 7 个字符),但足以清晰地展示「数字+单位」:

实时活动方案以及悬浮窗

更重要的事,它看起来不像是第三方的补丁,而更像是系统自带的原生功能——做到了干净、自然、无缝融合。

幕后故事:我负责提想法,AI 负责写代码

AI 时代的到来彻底改变了个人开发的门槛。

以前我也曾尝试开发过一些小工具(比如自动跳过广告的 App),但往往因为初期繁琐的代码构建和漫长的正反馈周期而「弃坑」。投入精力太大、产出太慢,热情很容易被耗尽。

另一个从兴趣满满到再也不想打开的孵化项目

但这一次完全不同。在 Pixel Meter 的开发过程中,我采用了一种新的「人机协作」模式:

  • 我负责:架构设计、需求分析、以及在 AI 犯错时进行「代码审查」和方向纠正。
  • Gemini 负责:编写具体实现代码、生成文档、甚至处理上架素材。

我使用了 AntiGravity,配合自定义的 GEMINI.md 规则文件。这就像是给了 AI 一份「长期记忆」,让它能记住我们之前的架构讨论和代码规范;即使是新建会话,它也能读取这些「记忆文件」,快速进入开发状态。

AI4
让AI进行技术栈推荐与决策
AI5
架构设计讨论
新建会话时读取「记忆」文件让Gemini快速「回想」起项目的需求

最终的数据令人惊讶:Pixel Meter 目前已发布了 3 个版本,其中90% 的代码是由 Gemini 生成的。甚至连 GitHub 仓库的 README 文档、隐私政策,以及 Google Play 上的宣传文案和置顶图,都是由它操刀完成的。

邀请你来体验

目前,Pixel Meter 已经在 GitHub 开源,你也可以直接前往 Google Play 商店搜索「Pixel Meter」即可下载安装使用。

 

无论你是想体验一个纯净的网速显示工具,还是对 AI 辅助开发的代码质量感兴趣,都欢迎来试一试 Pixel Meter。

> 关注 少数派公众号,让你的 Google Pixel 更好用 📱

> 实用、好用的 正版软件,少数派为你呈现 🚀

    把以前写的饭否 iOS 客户端开饭使用 AI 重写了,感觉很不错了,很多功能我以前根本不会写,我只能说 AI 真的太强了

    更新日志:

    • 更流畅的体验

    • 转发、回复交互逻辑修改

    • 支持语音输入

    • 支持 ocr 输入

    • 拍照支持多种滤镜

    • iPad 上支持分屏界面

    • 支持自定义 tab 栏

    • 支持自定义字体

    • 支持分享图片、复制图片

    • 使用本机数据库存储 节省流量更流畅

    • 主题只保留黑色、白色和跟随系统

    • 增加一些动画效果

    • 下载链接

    https://apps.apple.com/hk/app/开饭-饭否客户端/id1189449526

    以前的我:
       这个我不会,这页面好卡,这里怎么闪退了
    
    现在有了 AI 的我:
       我现在强得可怕
    

    我现在强得可怕

    把以前写的饭否 iOS 客户端开饭使用 AI 重写了,感觉很不错了,很多功能我以前根本不会写,我只能说 AI 真的太强了

    更新日志:

    • 更流畅的体验

    • 转发、回复交互逻辑修改

    • 支持语音输入

    • 支持 ocr 输入

    • 拍照支持多种滤镜

    • iPad 上支持分屏界面

    • 支持自定义 tab 栏

    • 支持自定义字体

    • 支持分享图片、复制图片

    • 使用本机数据库存储 节省流量更流畅

    • 主题只保留黑色、白色和跟随系统

    • 增加一些动画效果

    • 下载链接

    https://apps.apple.com/hk/app/开饭-饭否客户端/id1189449526

    以前的我:
       这个我不会,这页面好卡,这里怎么闪退了
    
    现在有了 AI 的我:
       我现在强得可怕
    

    我现在强得可怕

    利益相关声明:作者与文中产品有直接的利益相关(开发者、自家产品等)

    Matrix 首页推荐 

    Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。 

    文章代表作者个人观点,少数派仅对标题和排版略作修改。


    AI 辅助创作声明:

    本文由 Gemini 生成题纲,我完成内容创作,文章由 Gemini 后期润色。个人文笔不好,如对 AI 生成内容敏感还请见谅!


    引言:原生党的「网速焦虑」与「毛坯房」

    正在使用 Pixel 或类原生系统的朋友,对「毛坯房」这个调侃应该也并不陌生。虽然我们享受着最纯粹的 Android 体验,但总有一些本地化功能的缺失让人抓狂,「实时网速显示」就是其中之一。

    在国内复杂的网络环境下,网速显示对我而言几乎是刚需。但尴尬的是 Google 似乎从未打算在系统层面支持这一功能。于是我们不得不转向 Google Play 商店寻找第三方解决方案。然而当我翻遍了市场上的同类应用,如 NetSpeed Indicator、Internet Speed Meter 等,却发现这些「老牌应用」在 2026 年的今天体验依然难以令人满意:它们大多有着过时的 UI 设计,许多 App 的界面还停留在 Android 4.4 或初代 Material Design 时期,放在当下的 Android 系统中总会显得格格不入;实际网速显示效果也一般,要么是状态栏上那个看不清数字和单位的小图标,要么是拖着「正在其他应用上层显示」膏药的悬浮窗;另外功能臃肿也是个问题,我只想要一个网速显示,它们却往往附赠了流量统计、详单分析等一堆我不需要的功能。

    更致命的是,它们都有一个共同的痛点:开启代理工具时网速统计严重虚高。Pixel 用户应该遇到过这种情况,明明下载速度只有 5MB/s,网速悬浮窗却显示 10MB/s。

    为什么这些工具的网速总是不准?

    简单来说,这是 Android 旧版统计机制的「锅」。 传统的网速 App 通常直接读取系统的总流量接口,开启代理工具后,数据包首先通过物理网卡(如 wlan0)进入被统计一次,随后数据被解包并转发到代理工具的虚拟接口(如 tun0),这里又会被统计一次。

    大多数老牌 App 只是简单地将所有接口流量相加,导致显示速度往往是实际速度的 2 倍。

    好在最近 AI 编程确实火热,既然找不到完美的替代品,我萌生了一个想法:为什么不让 AI 帮我写一个专门适配 Pixel 的网速 App 呢?

    于是 Pixel Meter 诞生了。

    Pixel Meter 到底好在哪?

    作为一款以解决个人需求为出发点的 App,Pixel Meter 主要解决了两个核心问题。

    精准的流量统计(告别虚高)

    Pixel Meter 摒弃了过时的全局统计方案,转而利用 Android S (API 31) 引入的新 API TrafficStats.getRxBytes(ifaceName)

    这个 API 允许 App 精确获取指定网络接口的流量数据,通过内置的网卡白名单与黑名单机制,Pixel Meter 能智能过滤掉代理工具虚拟接口的重复数据。最重要的是,实现这一功能不需要 Root 也不需要 Shizuku 权限,做到了既高效又精准。

    可能是目前最优雅的展示方式

    实时活动通知(Live Update Notification)是我认为 Pixel Meter 最大的撒手锏,在 Android 16 及部分支持该特性的高版本系统中,实时活动通知相比于传统状态栏图标,不会有显示空间受限、可读性差等问题,允许我们灵活展示更丰富的内容。

    不妨看个对比:

    传统方案:拥挤的状态栏,数字和单位难以看清

    Pixel Meter 则利用通知区域的实时更新特性,虽然有字符限制( 7 个字符),但足以清晰地展示「数字+单位」:

    实时活动方案以及悬浮窗

    更重要的事,它看起来不像是第三方的补丁,而更像是系统自带的原生功能——做到了干净、自然、无缝融合。

    幕后故事:我负责提想法,AI 负责写代码

    AI 时代的到来彻底改变了个人开发的门槛。

    以前我也曾尝试开发过一些小工具(比如自动跳过广告的 App),但往往因为初期繁琐的代码构建和漫长的正反馈周期而「弃坑」。投入精力太大、产出太慢,热情很容易被耗尽。

    另一个从兴趣满满到再也不想打开的孵化项目

    但这一次完全不同。在 Pixel Meter 的开发过程中,我采用了一种新的「人机协作」模式:

    • 我负责:架构设计、需求分析、以及在 AI 犯错时进行「代码审查」和方向纠正。
    • Gemini 负责:编写具体实现代码、生成文档、甚至处理上架素材。

    我使用了 AntiGravity,配合自定义的 GEMINI.md 规则文件。这就像是给了 AI 一份「长期记忆」,让它能记住我们之前的架构讨论和代码规范;即使是新建会话,它也能读取这些「记忆文件」,快速进入开发状态。

    AI4
    让AI进行技术栈推荐与决策
    AI5
    架构设计讨论
    新建会话时读取「记忆」文件让Gemini快速「回想」起项目的需求

    最终的数据令人惊讶:Pixel Meter 目前已发布了 3 个版本,其中90% 的代码是由 Gemini 生成的。甚至连 GitHub 仓库的 README 文档、隐私政策,以及 Google Play 上的宣传文案和置顶图,都是由它操刀完成的。

    邀请你来体验

    目前,Pixel Meter 已经在 GitHub 开源,你也可以直接前往 Google Play 商店搜索「Pixel Meter」即可下载安装使用。

     

    无论你是想体验一个纯净的网速显示工具,还是对 AI 辅助开发的代码质量感兴趣,都欢迎来试一试 Pixel Meter。

    > 关注 少数派公众号,让你的 Google Pixel 更好用 📱

    > 实用、好用的 正版软件,少数派为你呈现 🚀

      钱没赚到,生活还要继续 · R 门

      现状

      今年整体一个字:稳。
      不温不火,谈不上大富大贵,但也还没到要去送外卖。

      工作上没什么戏剧性变化。
      部门今年开始有一些 AI 相关需求,
      顺手糊了个 AI Agent ,
      一开始也没抱多大期望,
      结果效果还行,至少在 PPT 里能算个「亮点」。

      AI:今年最大的变量

      如果说 2024 年的 AI 只是:

      “把代码丢进网页,看它胡说八道”
      

      那 2025 年基本是:

      “看 AI 写代码,我负责怀疑人生”
      

      Claude Code / Codex / Antigravity

      每一个出来都让我有点绷不住。
      这里必须单独说一下 Codex 。

      它修 bug 并不快,
      但问题在于:找得准。

      经常是那种:

      • 没大改
      • 不重构
      • 甚至改动行数不超过 3 行

      但就是能直接命中问题点,
      精准告诉你该动哪一行。

      对我这种写了 10+ 年代码的人来说,
      冲击感不在于速度,
      而在于它对代码结构和因果关系的理解,
      已经明显超过了“工具”的范畴。

      现在 Claude Code 在本地已经不止写代码了:

      • 十几个 Excel 要筛选 → 丢给 Claude
      • 混淆过的 JS 要破解 → 还是 Claude

      目前的感觉是:

      Claude 基本什么都能干,除了替我加薪。

      展望

      不想给自己立太多 flag:

      • 希望家人身体健康
      • 希望新的一年能看到点 真正硬核的技术突破

      比如:

      • 固态电池别再 PPT 了
      • 机器人能早点干点脏活累活

      最后,例行秀一下代码

      钱没赚到,
      但仓库里多少还是有点动静的。

      一个小开源项目:
      👉 https://github.com/lsk569937453/rcurl

      不一定有人用,
      但至少证明今年不是完全在摸鱼。