无尘阁日记

现在企业遇到的对AI转型的迷茫问题

Sat, 09 May 2026 14:57:40 +0800

她主要提出的不是一个单点问题，而是一组企业 AI 转型的真实痛点。可以概括成 6 个核心问题：

一、不知道 AI 到底能用在哪里

她说的第一个痛点是：

企业不知道 AI 能够在哪些环节使用。

也就是说，老板和团队现在不是完全不想转，而是不知道从哪里切进去。

具体包括：

1. 哪些业务环节可以用 AI？

比如销售、客服、研发、运营、交付、财务、人事、产品设计、项目管理，到底哪些环节最适合先做 AI 化？

2. 哪些场景值得做？

不是所有地方都值得上 AI。企业真正需要知道的是：

哪些场景用了 AI 之后，能降本、提效、增收、提升竞争力？

她关心的不是工具炫技，而是业务价值场景识别。

二、不知道先进企业是怎么做的

她第二个问题是：

想知道别人先进企业已经怎么转型，有哪些经验可以直接借鉴。

这里她的潜台词是：

企业自己摸索成本太高，时间也来不及，希望看到已经验证过的路径。

她需要的是：

1. 标杆案例

比如字节、阿里、腾讯、华为，或者行业内领先公司，是怎么把 AI 用到组织、产品、研发、运营里的。

2. 可复制经验

不是听故事，而是要知道：

人家为什么这么做？做了哪些步骤？用了什么组织机制？踩过什么坑？哪些东西我们可以直接借鉴？

3. 少走弯路

她特别强调“少走弯路”，说明企业现在最大的焦虑之一是：

信息很多，但不知道哪些是真经验，哪些是噪音。

三、不知道 AI 转型应该怎么转

这是她讲得最核心的问题。

她说：

真正转，怎么转？从哪里开始？步骤是什么？一般规律是什么？会有哪些坑？

这个问题可以拆成四层：

1. 从哪里开始？

企业 AI 转型不能一上来就全公司大改，需要找到第一批试点场景。

比如：

先从内部提效开始？
先从产品 AI 化开始？
先从研发流程重构开始？
先从老板关心的经营分析开始？

她想知道第一步怎么走。

2. 转型路径是什么？

也就是企业 AI 转型有没有一套路线图：

认知统一 → 场景盘点 → 试点验证 → 流程重构 → 工具沉淀 → 组织配套 → 产品升级 → 持续迭代

她现在缺的就是这个“路径感”。

3. 转型规律是什么？

不同企业虽然行业不同，但 AI 转型背后可能有共性规律。

比如：

先提效，后增收
先局部试点，后组织推广
先流程标准化，再智能化
先解决高频、重复、明确边界的问题
先让团队会用，再谈系统重构

她希望有人把这些规律讲清楚。

4. 会踩哪些坑？

她担心企业盲目上 AI，比如：

只买工具，不改流程
只培训员工，不改考核
只做演示，不进业务系统
老板很焦虑，但团队不知道怎么执行
AI 项目看起来热闹，最后没有业务结果

四、软件行业自身会被 AI 重构

她所在企业应该和软件行业相关，所以她特别强调：

软件行业可能是受冲击最大的。AI 来了之后，软件生产流程已经被重构了。

这个问题非常关键。

她不是泛泛谈 AI，而是在问：

AI 时代的软件工程到底怎么变？

过去软件公司的生产流程可能是：

需求分析 → 产品设计 → UI设计 → 前端开发 → 后端开发 → 测试 → 部署 → 运维

但 AI 介入后，整个流程都可能变化：

需求文档可以 AI 辅助生成
原型可以 AI 辅助设计
代码可以 AI 辅助编写
测试用例可以 AI 自动生成
文档可以 AI 自动整理
项目管理可以 AI 辅助跟踪
客户支持可以 AI 辅助响应

所以她真正的问题是：

AI 时代，软件公司原来的研发体系、项目管理体系、交付体系，还适不适用？

五、团队能力模型要重新定义

她接着说：

软件工程路径变化了，对人的要求就会变化，对能力的要求也会变化。

这句话非常重要。

她提出的是组织层面的第二个核心问题：

AI 转型之后，人应该怎么变？

具体包括：

1. 岗位会不会变化？

比如：

程序员是不是要变成 AI 协作型工程师？
产品经理是不是要更懂 AI 场景设计？
测试是不是要会用 AI 生成测试用例？
项目经理是不是要掌握 AI 驱动的交付管理？
售前是不是要会做 AI 解决方案？

2. 能力要求会不会变化？

过去看重的是单点技能，比如写代码、做需求、测系统。

以后可能更看重：

提问题能力
拆解任务能力
设计流程能力
调用 AI 工具能力
验收 AI 结果能力
跨职能协同能力

3. 团队怎么升级？

她关心的是：

原来的团队怎么往新能力体系迁移？

这就涉及培训、考核、岗位重构、人才筛选、组织机制调整。

六、产品和服务怎么加入 AI，提升竞争力

她把问题分成两个方面：

一个方面是我们本身提供的产品和服务；第二个方面是组织和企业本身如何 AI 转型。

这里其实是两个赛道：

1. 对内：企业自身 AI 转型

也就是内部怎么用 AI 提效、降本、优化管理。

比如：

AI 辅助研发
AI 辅助运营
AI 辅助经营分析
AI 辅助人力资源
AI 辅助客户服务
AI 辅助知识管理

2. 对外：产品服务 AI 化

也就是她们自己的产品如何加入 AI 能力，变得更有竞争力。

比如软件企业原来卖系统，现在客户可能会问：

你这个系统有没有 AI？能不能自动分析？能不能自动生成？能不能智能推荐？能不能减少人工操作？

她担心的是：

如果自己的产品不 AI 化，可能会被同行或者跨界企业超越。

最后，她还有一个隐藏但很重要的问题：老板的战略焦虑

她最后提到：

信息特别多，老板天天收到很多信息，大家担心突然被其他行业超了。

这不是技术问题，而是战略焦虑。

可以总结为：

企业不知道自己现在走的方向对不对

她关心的是：

我们现在的 AI 方向是不是正确？
我们是不是在做真正有价值的事？
我们会不会被别的行业、别的公司突然超过？
我们该如何判断趋势？
我们的战略定义是否需要调整？

所以她不仅需要工具培训，更需要一套：

AI 时代企业战略判断框架。

一句话总结

她提出的核心问题是：

企业不是不想做 AI，而是不知道 AI 用在哪、怎么转、先做什么、别人怎么做、团队怎么变、产品怎么升级，以及自己的战略方向到底对不对。

更精炼地说，就是这 6 个问题：

序号	问题	本质
1	AI 可以用在哪些环节？	场景识别问题
2	先进企业怎么做？	标杆借鉴问题
3	企业 AI 转型怎么转？	路径方法问题
4	软件生产流程怎么被重构？	业务流程重构问题
5	团队能力怎么升级？	组织人才问题
6	产品和服务怎么 AI 化？	产品竞争力问题
7	方向到底对不对？	战略判断问题

如果用于你们后面设计产品，可以把她的需求提炼成一句话：

企业需要的不是一堂泛泛的 AI 课，而是一套“从战略判断、场景识别、路径设计、组织配套到产品 AI 化”的企业 AI 转型落地方案。

双方服务器时间戳不一致，导致凭证大概率过期

Fri, 08 May 2026 18:04:41 +0800

我问：

现在遇到一个问题，我这里颁发的一个凭证，时间戳可能比对方超前，然后加上60，到他那里就出现了有效期不正确的提示，我该怎么弄？把过期时间改小？

AI答：

不要优先把过期时间“改小”。真正问题不是 60 秒太长，而是 双方服务器时间不一致。

你现在的问题本质是：

你的服务器时间：12:00:30
对方服务器时间：12:00:00

你生成 expireTime = 12:01:30
对方拿到后判断：这个凭证有效期还有 90 秒，超过允许的 60 秒
于是提示：有效期不正确

也就是说，对方不是觉得它“过期了”，而是觉得它“有效期太长”或“签发时间在未来”。

一、正确处理顺序

1. 第一优先级：校准服务器时间

这是根治方案。

在你的服务器上先看时间：

date
timedatectl status

开启 NTP 自动校时：

sudo timedatectl set-ntp true

如果是 CentOS / Rocky / AlmaLinux，可以看：

chronyc tracking
systemctl status chronyd

如果你的程序跑在 Docker 里，注意：
容器时间一般跟宿主机走，所以要校准宿主机时间，不是只看容器。

二、如果短期无法让双方时间完全一致，怎么兼容？

你可以做一个“时间回拨补偿”。

比如你发现你们服务器普遍比对方快 30 秒，那就不要用本机当前时间直接签发，而是：

签发基准时间 = 当前时间 - 30 秒
过期时间 = 签发基准时间 + 60 秒

也就是：

$ttl = 60;
$clockOffset = 30; // 你方时间比对方快约 30 秒，就回拨 30 秒

$baseTime = time() - $clockOffset;
$expireTime = $baseTime + $ttl;

$payload = [
    'sub' => json_encode([
        'thirdparty' => 'norming',
        'module' => 'SELFBUILT',
        'tenantId' => $tenantId,
        'creditCode' => $creditCode,
        'expireTime' => $expireTime,
        'nonce' => bin2hex(random_bytes(8)),
    ], JSON_UNESCAPED_UNICODE),
    'iat' => $baseTime,
    'exp' => $expireTime,
];

这样对方看到的是：

iat：更接近对方当前时间
expireTime：距离对方当前时间约 60 秒

比单纯把过期时间改小更稳。

三、为什么不建议直接把过期时间改小？

比如你直接从：

expireTime = 当前时间 + 60

改成：

expireTime = 当前时间 + 30

短期可能能过，但会带来两个问题：

第一，真实可用时间变短。网络慢一点、接口排队一下、重试一次，凭证可能就过期了。

第二，时间偏差一变又会失败。今天你们快 30 秒，明天快 45 秒，后天 NTP 恢复正常，它又不稳定了。

所以更好的做法是：

不是单纯缩短有效期，而是修正签发基准时间。

四、最好让对方加“时间容忍窗口”

如果能跟对方沟通，建议他们校验时允许一定时间误差，比如 ±60 秒或 ±120 秒。

正确校验逻辑应该类似：

iat 不能明显晚于对方当前时间，比如不能超过 now + 60
expireTime 不能早于对方当前时间，比如不能小于 now - 60
expireTime - iat 应等于或不超过 60 秒

不要死板地判断：

expireTime - 当前时间 必须小于等于 60 秒

因为这个判断天然怕服务器时间误差。

五、你们这个“诺明凭证”建议统一成这样

你之前那个 token 里有两个过期时间：

sub.expireTime：60 秒后
JWT 外层 exp：7 天后

这个不太好，容易导致对方系统校验逻辑分裂。

建议统一：

iat = 签发基准时间
exp = 签发基准时间 + 60
sub.expireTime = 签发基准时间 + 60

也就是外层 exp 和内层 expireTime 保持一致。

六、最终建议

你现在不要简单理解成“把过期时间改小”。

更准确的处理是：

1. 先校准你方服务器时间；
2. 如果短期仍有偏差，就做签发时间回拨补偿；
3. iat、exp、sub.expireTime 使用同一个基准时间；
4. 最好让对方加 60～120 秒 clock skew 容忍；
5. 如果偏差超过 60 秒，靠凭证参数硬调不可靠，必须校时。

你可以临时先这样改：

baseTime = time() - 30
expireTime = baseTime + 60

如果对方仍提示有效期不正确，再把 30 调成 45 或 60。但这只能算临时兜底，最终还是要把服务器时间同步好。

git幽灵模式是啥？

Fri, 08 May 2026 16:04:07 +0800

你这个朋友说的“Git 幽灵模式”，大概率不是 Git 官方概念，而是一种圈内说法。它说白了是：

仓库、分支、版本虽然被删了，但 Git 的某些对象、历史记录、缓存、镜像、构建产物，可能还在。只要知道关键版本标识，就有机会把曾经存在过的内容找回来。

但这里要分清楚：
这不是魔法，也不是 Git 自带的“隐身入口”。更不是说任何删除的仓库都能随便拿到。

一、为什么删除了还能找回来？

因为 Git 的核心不是“文件夹”，而是一套对象数据库。

Git 里面主要有几类对象：

对象	通俗解释
blob	一个文件的内容
tree	一个目录结构
commit	一次提交快照
tag	给某个版本打的标签

你平时看到的分支，比如：

main
dev
release-v1.0

本质上只是一个“指针”。

它指向某个 commit。

所以删除分支，并不一定立刻删除 commit 本身。

举个简单例子：

main  →  A → B → C

如果把 main 这个分支删掉，可能只是把 main 这个指针删了。

但是 A、B、C 这些提交对象，可能还暂时躺在 Git 的对象库里。

这就像一本书的目录被撕掉了，但书页还没被烧掉。

二、他说的“曾经删除过的版本”是什么意思？

一般有几种情况。

1. 删除的是分支，不是提交内容

比如一个仓库曾经有一个分支：

feature/secret-demo

后来这个分支被删了。

但是只要有人知道当时最后一次提交的 commit hash，比如：

a1b2c3d4e5f6...

并且这个对象还没被清理，就可能重新找回。

这就是所谓“幽灵版本”。

它看起来消失了，实际上对象还残留着。

2. 删除的是 tag，但版本归档还在缓存里

有些项目发布过版本：

v1.0.0
v1.0.1
v2.0.0

后来作者删了 tag，或者删了 release。

但如果这个版本曾经被：

下载过；
被别人 fork；
被 CI 构建过；
被镜像站同步过；
被包管理平台收录过；
被搜索引擎或归档服务缓存过；

那么它就可能不在原仓库里，却还存在于别的地方。

这也是很多“删除后还能被找到”的原因。

3. 删除的是仓库，但别人 fork 或 clone 过

Git 是分布式版本控制。

这点很关键。

SVN 那类系统更像“中央仓库”；
Git 则是每个人本地都可以有一份完整历史。

所以一个仓库即使原作者删除了：

原始仓库：删除
别人 fork：还在
别人本地 clone：还在
CI/CD 缓存：可能还在
镜像站：可能还在
包管理平台：可能还在

所以删除原仓库，不等于全网蒸发。

这也是很多开源项目“删库跑路”后，代码还能被恢复的原因。

三、“版本号”和“加密字符串”可能指什么？

你截图里说：

只要能找到版本号和加密字符串

这个说法不太标准。这里面可能混了几个概念。

1. 版本号

版本号可能是：

v1.0.0
v1.2.3
2024.10.15
release-2025-01

它通常对应一个 tag、release、构建包或者历史快照。

2. 所谓“加密字符串”

这个词大概率不准确。

很多人会把下面这些东西都叫“加密字符串”：

他说的“加密字符串”	实际可能是
一串很长的字符	commit hash
SHA 字符串	Git 对象 ID
下载链接里的 token	临时签名 URL
release 包地址参数	CDN 缓存 key
CI 构建编号	artifact 标识
压缩包校验值	checksum
访问凭证	access token，敏感信息

Git 里的 commit hash 不是加密字符串，而是哈希值。

比如：

9fceb02c4e21...

它的作用类似“身份证号”。

知道这个 commit hash，就可能定位到某个历史版本。

但前提是：

这个对象还存在；
你有访问权限；
平台没有清理；
没有被彻底垃圾回收；
不是私有仓库或受限资源。

四、所谓“幽灵模式”的技术本质

我给你拆成一句话：

Git 幽灵模式，本质上是利用 Git 的历史对象、残留引用、缓存归档、fork、镜像、CI 产物、包管理平台记录等路径，寻找曾经存在过但现在不在主视野里的代码版本。

它不是单一技术，而是一类现象。

常见来源有这些：

1. 本地残留

开发者电脑里可能还有：

.git 目录
reflog
旧分支
stash
未清理的 commit

比如自己误删分支，通常可以从本地恢复。

2. 远程残留

远程 Git 平台可能短期保留一些对象。

但这取决于平台策略，不是稳定能力。

3. Fork 残留

别人 fork 过以后，原仓库删除，fork 可能还在。

4. Clone 残留

别人本地 clone 过，哪怕原仓库没了，本地副本还在。

5. Release / Tag 残留

项目发布过版本包，后来仓库删了，但包可能在其他地方还存在。

6. CI/CD 产物残留

比如 GitHub Actions、GitLab CI、Jenkins、Docker Registry 里可能还有：

构建包
镜像
日志
压缩包
测试报告
部署包

7. 包管理平台残留

比如：

npm
PyPI
Composer Packagist
Docker Hub
Maven
Go proxy

这些平台可能缓存过某个版本。

所以代码虽然 Git 仓库删了，但发布包还可能存在。

五、它是不是黑客技术？

看用途。

合法场景

比如你自己的项目误删了：

仓库删了；
分支删了；
tag 删了；
release 删了；
某个版本找不到了；

这时候通过 Git 历史、reflog、备份、fork、CI 产物恢复，是正常的工程恢复手段。

高风险场景

如果是：

获取别人删除的私有仓库；
找泄漏源码；
利用 token 或签名链接绕过访问控制；
恢复别人已经撤回的敏感代码；
搜索密钥、账号、配置文件；

那就不只是技术问题了，可能涉及越权访问、数据泄露、商业秘密和法律风险。

所以这个东西可以科普原理，但不能把它当成“捡别人源码”的方法。

六、它和普通 Git 恢复有什么区别？

普通 Git 恢复一般是自己仓库里操作。

比如：

我删了分支 → 从 reflog 找回来
我删了 commit → 从 fsck 找回来
我删了文件 → 从历史版本恢复

而所谓“幽灵模式”更像外部视角：

原仓库删了
但是历史版本、缓存、fork、镜像、构建包还在
于是从这些地方拼回曾经存在过的版本

所以它听起来更神秘，但本质还是 Git 的分布式特性和互联网缓存特性。

七、为什么“删除”不等于“彻底删除”？

因为数字世界里的删除，经常只是“入口删除”。

比如：

删除仓库页面 ≠ 删除所有 fork
删除分支名 ≠ 删除 commit 对象
删除 release ≠ 删除别人下载过的压缩包
删除 GitHub 仓库 ≠ 删除 Docker 镜像
删除源码 ≠ 删除 npm / PyPI / Composer 包
删除 tag ≠ 删除 CI 构建产物

真正彻底删除，需要同时处理：

Git 历史；
分支；
tag；
release；
fork；
镜像；
本地 clone；
CI/CD artifact；
Docker 镜像；
包管理平台；
CDN 缓存；
搜索引擎缓存；
第三方归档。

这也是为什么很多公司一旦把密钥提交到 Git，哪怕马上删掉，也要立刻更换密钥，而不是只删代码。

八、如果是自己的仓库误删，应该怎么恢复？

可以按这个顺序找。

第一优先级：本地电脑

如果你本地曾经 clone 过，成功率最高。

重点找：

.git 目录
本地分支
reflog
stash
未推送 commit

第二优先级：同事电脑

如果团队其他人 clone 过，让他们检查本地仓库。

Git 是分布式的，只要有人有完整 clone，就可能恢复。

第三优先级：远程平台

看 GitHub、GitLab、Gitee 是否支持恢复删除仓库。

不同平台策略不同，有的有短期恢复窗口，有的需要联系管理员或平台支持。

第四优先级：Fork 和镜像

看看有没有：

fork 仓库
mirror 仓库
备份仓库
只读同步仓库

第五优先级：CI/CD 和部署服务器

服务器上可能有：

部署目录
构建包
vendor 目录
dist 目录
Docker 镜像
CI artifact

第六优先级：包管理平台

如果项目发布过包，可以找：

npm
PyPI
Packagist
Docker Registry
Maven
Go proxy

九、如果是企业系统，怎么防止“幽灵版本”泄密？

这点很重要。

1. 不要把密钥写进 Git

比如这些东西绝对不要提交：

数据库密码
JWT 密钥
SMTP 密码
OAuth secret
Access Token
.env 文件
私钥文件
API Key

2. 一旦泄漏，立刻轮换

不要只删 commit。

正确动作是：

删除泄漏内容
重写历史
强制推送
清理 fork / mirror
废弃旧密钥
生成新密钥
检查访问日志
通知相关系统

核心是：密钥泄漏以后，删除代码不够，必须换密钥。

3. Git 提交前做扫描

可以接入：

gitleaks
trufflehog
git-secrets
GitHub Secret Scanning
GitLab Secret Detection

4. CI/CD 里也要清理

很多人只清理 Git 仓库，忘了 CI 产物。

但泄漏信息可能还在：

构建日志
测试日志
Docker 镜像层
artifact 压缩包
部署包
缓存目录

十、你可以这样理解这个朋友的话

他那句话翻译成正常技术语言，大概是：

我不是从当前公开仓库入口拿到的，而是通过历史残留版本、缓存、归档、fork 或 Git 对象定位到的。这个版本曾经存在过，后来被删除了。但只要能找到对应版本号、commit 标识、归档链接或访问凭证，就可能重新定位到那个历史版本。

但是要注意，他说的“加密字符串”这个词不严谨。

更准确可能是：

commit hash
tag
release 编号
构建编号
签名 URL
对象 ID
访问 token
校验 hash

其中如果涉及 token 或签名 URL，那就是敏感凭证，不应该传播和使用。

十一、最简洁总结

Git 幽灵模式不是官方功能，而是一个民间说法。

它说的是：

一个 Git 仓库或版本虽然被删除了，但因为 Git 的分布式历史、对象残留、fork、clone、缓存、release、CI 产物、包管理平台等原因，曾经存在过的版本仍可能被找回。

但它有边界：

恢复自己的误删项目，是正常工程能力；
获取别人删除的私有仓库或泄漏源码，就是高风险甚至违法行为。

真正的重点不是“怎么捞别人删掉的代码”，而是要明白：

在 Git 世界里，提交过的东西很难真正消失。
所以敏感信息一旦进 Git，第一动作永远不是删除，而是轮换、作废、追踪和审计。

请详细解释下：git幽灵模式

Fri, 08 May 2026 16:01:08 +0800

一句话解释

Git 幽灵模式不是 Git 官方功能，而是一种口语化说法：
它通常指 AI 或开发者在不污染主分支、不直接影响当前工作区的情况下，悄悄在旁路环境里改代码、跑测试、生成差异，最后再由人确认是否合并。

更通俗点说：

正常模式：你直接在当前项目里改代码。
幽灵模式：AI 先在“影子分支 / 影子目录 / 临时工作区”里改，改完给你看差异，你点头后再进正式代码库。

Git 官方没有“ghost mode”这个命令；比较接近的底层能力是 branch、worktree、stash、diff、commit、PR 这一套组合。Git worktree 可以让同一个仓库在多个目录里同时检出不同分支，每个 worktree 有自己的 HEAD、索引等工作区状态；stash 则可以临时保存当前修改并把工作区恢复干净。(Git)

一、它到底“幽灵”在哪里？

所谓“幽灵”，主要体现在三点。

1. 不直接动主分支

比如你当前在：

main

AI 不直接在 main 上改，而是新建一个临时分支：

ai/fix-login-error

这样哪怕 AI 改坏了，也不会污染正式代码。

2. 不打断你当前工作

你现在正在改 A 功能，突然让 AI 修 B 问题。
正常情况下，你得保存、切分支、切回来，很烦。

用 worktree 可以单独开一个目录：

git worktree add ../auto-workflow-ai -b ai/fix-login-error

这样你的原目录继续干 A，AI 在另一个目录修 B，互不影响。这个特别适合你现在这种 PHPStorm + AI 编码 + Git + 服务器部署 的流程。VS Code 文档里也把 worktree 作为多分支并行开发的一种方式，JetBrains 文档也明确提到它可用于 AI 驱动开发，避免 AI 覆盖本地未保存修改。(Visual Studio Code)

3. 先产生差异，不直接合并

AI 改完以后，你先看：

git diff
git status

确认没问题，再：

git add .
git commit -m "fix: 修复登录数据库配置读取问题"
git push origin ai/fix-login-error

最后通过 Pull Request 或手动 merge 合进主分支。

二、放到你的系统里，应该怎么理解？

你现在的目标大概是：

本地代码由 AI 辅助修改，Git 记录版本，测试流程先跑一遍，通过后再提交仓库，服务器再自动拉取或自动部署。

那“Git 幽灵模式”在你的场景里，可以理解成：

AI 影子开发区

也就是给 AI 一个单独的分支和目录，让它在里面改 Yii / Laravel / PHP 项目代码。

例如你的项目叫：

auto-workflow

可以这样做：

cd /www/wwwroot/workflow.jiangtian.top/auto-workflow

git worktree add ../auto-workflow-ai -b ai/fix-auth-login

这时候会出现两个目录：

auto-workflow        # 你的正式开发目录
auto-workflow-ai     # AI 幽灵工作区

AI 只在 auto-workflow-ai 里面改。

三、标准流程应该是这样

第一步：给 AI 开一个幽灵分支

git worktree add ../auto-workflow-ai -b ai/fix-env-config

含义是：

新建一个目录：../auto-workflow-ai
新建一个分支：ai/fix-env-config
AI 的所有修改都在这个分支里完成

第二步：让 AI 在这个目录里改代码

比如你让 AI 修：

.env 不生效；
Yii3 数据库配置读取失败；
api/auth/login 登录异常；
debug 面板启动问题；
单元测试缺失问题。

AI 改完后，不要马上合并。

先看：

git status
git diff

第三步：跑测试

PHP 项目可以先跑：

composer test

或者：

vendor/bin/phpunit

如果还没配置完整测试，至少先跑：

php -l path/to/file.php

检查 PHP 语法。

第四步：提交 AI 分支

git add .
git commit -m "fix: 修复环境变量加载与数据库连接配置"
git push origin ai/fix-env-config

第五步：人工确认后合并

cd ../auto-workflow

git fetch origin
git merge --no-ff ai/fix-env-config

或者走 GitHub / GitLab 的 Pull Request。

第六步：清理幽灵工作区

git worktree remove ../auto-workflow-ai

四、它和普通 Git 分支有什么区别？

本质上，它还是 Git 分支。

区别在于：普通分支通常在同一个目录里来回切；幽灵模式通常用 worktree 开一个独立目录。

对比项	普通分支切换	Git 幽灵模式
工作目录	一个目录	多个目录
是否打断当前开发	容易打断	不打断
是否适合 AI 自动改代码	一般	很适合
风险	AI 可能污染当前工作区	风险隔离
适用场景	人自己开发	AI 并行开发、临时修 bug、实验性改造

五、它和 stash 有什么关系？

stash 也有点“幽灵”的味道。

比如你正在改代码，但暂时不想提交，可以：

git stash push -m "临时保存当前修改"

Git 会把当前修改存起来，并把工作区恢复到干净状态。Git 官方文档对 stash 的描述就是：记录当前工作目录和索引状态，然后让工作目录回到干净状态。(Git)

但我不建议你把 stash 当主流程。
因为 stash 更像“临时抽屉”，适合短期保存，不适合 AI 长时间开发。

你的场景更适合：

git worktree + 独立分支 + 测试 + PR

六、它和 CI/CD 怎么接起来？

你的完整链路应该是：

AI 幽灵分支改代码
        ↓
本地跑测试
        ↓
提交到 Git 仓库
        ↓
触发 CI 流水线
        ↓
自动跑单元测试 / 语法检查 / 代码规范检查
        ↓
通过后允许合并
        ↓
服务器自动拉取或自动部署

也就是说，幽灵模式解决的是：

AI 在哪里安全地改代码？

CI/CD 解决的是：

改完以后，怎么自动验证、自动部署？

二者不是一回事，但可以完美配合。

七、千万不要把“幽灵模式”理解错

它不是让你“偷偷改代码、无痕提交、绕过审计”。

Git 里提交本来就有作者和提交者信息，而且作者名、邮箱等信息可以通过配置或环境变量影响提交身份；正因为如此，团队协作里更应该要求真实身份、签名提交、PR 审查，而不是搞“无痕提交”。(内核网站)

正确理解是：

幽灵模式 = 安全隔离的影子开发区。
不是无痕模式，也不是绕过审计。

八、我建议你以后就按这个口径讲

你可以这样对别人解释：

Git 幽灵模式不是 Git 的官方按钮，而是一种 AI 编码场景下的安全工作流。它通过独立分支、独立 worktree、diff 审查、测试验证和 PR 合并，让 AI 可以在旁路环境里先完成代码修改，不直接污染主分支。这样既能让 AI 自动写代码，又能保留 Git 版本记录、测试流程和人工审核，适合企业项目里的 AI 辅助开发、Bug 修复和自动化流水线建设。

这个说法比较稳，既专业，又不会吹得玄乎。

openrouter是啥？介绍下。

Fri, 08 May 2026 12:26:51 +0800

一句话说明

OpenRouter 就是一个“AI 模型统一入口”。
你不用分别去接 OpenAI、Anthropic、Google、xAI、DeepSeek、Qwen 等不同厂商的 API，而是通过 OpenRouter 一个接口，调用很多家的模型。

可以把它理解成：

OpenRouter = AI 模型版的“路由器 / 聚合网关 / 中转平台”。

它自己通常不训练模型，核心价值是：帮你统一调用、统一计费、统一切换模型、统一做备用线路。

1. 它解决什么问题？

如果你自己开发 AI 应用，正常情况会遇到这些麻烦：

问题	没有 OpenRouter	用 OpenRouter
调 OpenAI	接 OpenAI API	一个接口
调 Claude	再接 Anthropic API	一个接口
调 Gemini	再接 Google API	一个接口
调 DeepSeek/Qwen 等	再分别接	一个接口
模型价格对比	自己查各家	平台统一看
模型挂了	自己写 fallback	可用路由/备用能力
切模型	改很多代码	改 model 名称即可

OpenRouter 官方说它提供 one API for any model，并且 OpenAI SDK 可以直接兼容使用；它的 API schema 也和 OpenAI Chat API 很接近，用来统一不同模型和供应商的请求格式。(OpenRouter)

2. 它不是模型，而是“模型超市”

你可以在 OpenRouter 上选择很多模型，比如：

厂商	典型模型类型
OpenAI	GPT 系列
Anthropic	Claude 系列
Google	Gemini 系列
Meta	Llama 系列
DeepSeek	DeepSeek 系列
阿里 / 通义	Qwen 系列
xAI	Grok 系列
Mistral	Mistral 系列

OpenRouter 当前对外主打的是一个统一接口访问大量模型，官方 pricing 页面写的是可访问 400+ AI models。(OpenRouter)

3. 典型用法是什么？

你在代码里原本可能这样接 OpenAI：

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY
});

使用 OpenRouter 时，大体思路变成：

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY
});

然后模型名换成 OpenRouter 上的模型标识，比如：

model: "anthropic/claude-sonnet-4.5"

或者：

model: "openai/gpt-4.1"

它的好处是：你代码层面仍然像调 OpenAI 一样调，但背后可以换很多模型。 OpenRouter 官方也明确说明，它提供 OpenAI-compatible completion API，可以直接调用，也可以用 OpenAI SDK。(OpenRouter)

4. 对你这种做 AI 工作流的人，价值在哪里？

我觉得 OpenRouter 对你最有价值的地方，不是“能白嫖模型”，而是这几个：

4.1 做 AI 工具看板 / 智能体时，可以快速切模型

比如你做一个经营分析智能体，里面可以测试：

任务	可测试模型
长文档分析	Claude / Gemini / GPT
代码生成	Claude / GPT / Qwen Coder
中文报告	GPT / Qwen / DeepSeek
低成本批处理	小模型 / 免费模型
高质量推理	强推理模型

你不用每次改一套厂商 API，只要改 model 名称。

4.2 做成本控制

不同模型价格差异很大。
同一个任务，用顶级模型可能很贵，用中等模型可能已经够用。

OpenRouter 的 pricing 页面支持查看模型价格，按 token 计费；它还支持 pay-as-you-go，不是必须月付订阅。(OpenRouter)

对你来说，课程演示、客户陪跑、自动化报告生成，都可以按任务分层：

任务等级	模型策略
粗筛资料	便宜模型
提取结构	中等模型
写最终报告	强模型
代码调试	编程强模型
管理层汇报稿	表达强模型

这才是 OpenRouter 的真正商业价值。

4.3 做 fallback 备用线路

比如你原来只接一个模型：

模型挂了 = 整个系统不可用。

OpenRouter 支持 provider routing / fallback 思路，默认会把请求路由到可用供应商，也可以在请求体里设置 provider 规则。(OpenRouter)

这对企业项目很重要。
不是为了炫技，而是为了避免客户演示时突然翻车。这个场景你肯定懂，现场翻车比代码 bug 更让人心梗。

5. OpenRouter 和 API Key 是什么关系？

你注册 OpenRouter 后，会拿到一个 OpenRouter API Key。

你也可以使用 BYOK：Bring Your Own Key，意思是：
你把自己在 OpenAI、Anthropic、Google 等平台的 API Key 接进 OpenRouter，然后仍然通过 OpenRouter 的统一接口调用。OpenRouter 官方公告里说，BYOK 可以使用你自己的 provider API key，并且支持超过 60 个 inference providers；截至其公告，前 100 万 BYOK 请求/月免费，超过后按通常 5% 费率收取。(OpenRouter)

通俗讲就是：

模式	钱付给谁	适合谁
OpenRouter 余额模式	付给 OpenRouter	简单、省事
BYOK 模式	主要付给原厂商，OpenRouter 做路由	已经有各家 API Key 的团队

6. 它和 ChatGPT 有什么区别？

对比项	ChatGPT	OpenRouter
定位	面向用户的聊天产品	面向开发者的模型 API 平台
主要使用方式	网页 / App 聊天	API 调用
是否自己是模型	背后使用 OpenAI 模型	聚合很多模型
适合谁	普通用户、写作、分析、办公	开发者、AI 应用、智能体、工作流
是否方便集成系统	不如 API 灵活	很适合集成

一句话：

ChatGPT 是你直接用的 AI 助手；OpenRouter 是你开发 AI 助手时用的模型调度平台。

7. 它适合哪些场景？

很适合

场景	原因
AI 应用开发	一套接口调用多模型
智能体系统	方便不同任务分配不同模型
OpenClaw / 工作流平台	适合做模型网关
企业内部 AI 中台	方便统一模型入口
编程工具接入	可切 Claude、GPT、Qwen Coder 等
成本测试	方便比较不同模型价格和效果
课程演示	模型切换快，演示效果明显

不太适合

场景	原因
完全不写代码的人	使用门槛比 ChatGPT 高
只想聊天	直接用 ChatGPT / Claude 更简单
极高隐私数据	要仔细看数据流和服务条款
对大陆网络稳定性要求极高	可能还要考虑网络、支付、合规问题

8. 使用时要注意什么？

8.1 不要把它当成“免费模型神器”

它有免费模型和免费额度，但免费模型一般会有速率限制、可用性波动。OpenRouter pricing 页面说明 free 用户有限制，pay-as-you-go 用户付费模型没有平台级限制，但免费模型仍可能有限制。(OpenRouter)

所以：

学习测试可以用免费模型，正式项目最好按付费模型设计。

8.2 不要把敏感客户数据随便丢进去

OpenRouter 是中间层，背后还会路由到不同 provider。
如果是客户经营数据、财务数据、人事数据、合同数据，最好先做：

脱敏；
字段替换；
权限控制；
日志隔离；
明确选择模型供应商；
看清数据隐私条款。

8.3 国内访问和支付可能需要额外处理

这一点要现实一点。
OpenRouter 面向全球开发者，国内网络、支付、模型可访问性都可能受环境影响。正式部署时，要测试：

项目	要测什么
网络	是否稳定访问
延迟	响应是否可接受
支付	是否能充值
模型	目标模型是否可用
失败重试	超时后怎么处理
日志	是否记录敏感内容

9. 你可以怎么用它？

结合你现在做的 AI 工具看板、AI 工作流、OpenClaw、小龙虾、企业经营分析，我建议你把 OpenRouter 放在这个位置：

用户 / 企业系统
        ↓
你的 AI 工作流 / 智能体 / 工具看板
        ↓
模型网关层：OpenRouter
        ↓
GPT / Claude / Gemini / Qwen / DeepSeek / Llama ...

也就是说：

不要把 OpenRouter 当成最终产品，而要把它当成你 AI 系统里的“模型调度层”。

这对你后面做“AI 中台化”“企业陪跑”“自动化经营分析”是有价值的。

10. 最后给你一个判断标准

你可以这样判断是否需要 OpenRouter：

只聊天、不开发

不用。
直接 ChatGPT、Claude、Gemini 就行。

要做自动化工作流 / AI 工具 / API 接入

值得用。
因为它能让你一套代码接很多模型。

要做企业级 AI 中台

可以重点研究。
但要把权限、隐私、成本、日志、fallback 设计清楚。

要做课程演示

很适合。
因为你可以现场展示：“同一个任务，不同模型效果和成本完全不同。”这个对管理层很有冲击力。

我的结论

OpenRouter 本质上是 AI 模型的统一 API 网关。

它最大的价值不是“便宜”，而是：

统一入口、多模型切换、成本比较、故障备用、快速集成。

对普通用户，它不是刚需；
对做 AI 自动化、智能体、企业 AI 应用的人，它很有用。

Gmail 发送邮件配置指南：MAIL_SMTP_PASS 到底在哪里获取？

Fri, 08 May 2026 11:37:50 +0800

Gmail 发送邮件配置指南：MAIL_SMTP_PASS 到底在哪里获取？

很多人在配置邮箱发送功能时，会卡在一个字段上：

MAIL_SMTP_PASS=

或者在 Laravel、Node.js、PHP 项目里看到类似配置：

MAIL_PASSWORD=
SMTP_PASS=
EMAIL_PASS=
MAIL_SMTP_PASS=

这几个字段本质上要填的，通常都是 Gmail 的应用专用密码。

它不是你的 Gmail 登录密码，也不是 Google Authenticator 里的 6 位验证码，更不是恢复代码。它是 Google 账号单独生成的一串 16 位应用密码，专门给程序、脚本、SMTP 服务使用。

一、先搞清楚：MAIL_SMTP_PASS 是什么？

如果你要用 Gmail 给别人发邮件，比如：

网站注册后发送验证码；
系统发送通知邮件；
Laravel / Yii / Node.js 后台自动发邮件；
用 SMTP 调用 Gmail 发信；
自动化工作流里发送提醒邮件；

那你一般需要配置 Gmail SMTP。

常见配置长这样：

MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=你的Gmail邮箱@gmail.com
MAIL_SMTP_PASS=你的应用专用密码
MAIL_ENCRYPTION=tls

这里的 MAIL_SMTP_PASS 填的就是 Google 应用专用密码。

它是一串 16 位字符，格式大概像这样：

abcd efgh ijkl mnop

放进 .env 文件时，通常去掉空格：

MAIL_SMTP_PASS=abcdefghijklmnop

二、在哪里获取 Gmail 应用专用密码？

重点来了。

它不在 Gmail 邮箱后台里。

很多人打开 Gmail，找设置、找转发、找 POP/IMAP，翻半天都找不到。因为这个密码是在 Google 账号安全设置 里面生成的。

最快入口是：

https://myaccount.google.com/apppasswords

如果你打不开，或者进去之后没有看到创建入口，就按下面步骤来。

三、完整获取步骤

1. 打开 Google 账号安全中心

先进入 Google 账号管理页面：

https://myaccount.google.com/security

也可以这样进：

右上角头像 → 管理你的 Google 账号 → 安全性

进去后，找到：

你登录 Google 的方式

这里会看到“两步验证”等安全设置。

2. 先开启两步验证

应用专用密码有一个前提：你的 Google 账号必须开启两步验证。

路径一般是：

安全性 → 你登录 Google 的方式 → 两步验证

根据提示开启即可。

你可以选择：

手机短信；
Google Authenticator；
Google Prompt；
安全密钥；
备用验证码。

建议至少绑定一个常用手机和一个身份验证器，避免以后登录麻烦。

3. 进入应用专用密码页面

两步验证开启后，再打开：

https://myaccount.google.com/apppasswords

这时候 Google 可能会要求你重新输入一次账号密码。

输入完成后，就会进入应用专用密码页面。

4. 创建一个应用密码

页面里通常会让你填写一个应用名称。

这里可以写：

SMTP

或者写得更清楚一点：

MAIL_SMTP_PASS

再或者写项目名：

我的网站邮件发送

名称只是方便你以后识别，这个名称不会影响实际使用。

填写后，点击：

创建

或者英文界面里的：

Create / Generate

5. 复制 16 位应用密码

创建完成后，Google 会显示一串 16 位密码。

大概长这样：

abcd efgh ijkl mnop

你要马上复制保存，因为这个密码通常只显示一次。

放进项目配置时，建议去掉空格：

MAIL_SMTP_PASS=abcdefghijklmnop

如果你后面忘记了，不能再次查看原密码，只能删除旧的，再重新生成一个新的。

四、常见项目配置示例

Laravel 配置示例

Laravel 里通常写在 .env 文件：

MAIL_MAILER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=你的Gmail邮箱@gmail.com
MAIL_PASSWORD=abcdefghijklmnop
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=你的Gmail邮箱@gmail.com
MAIL_FROM_NAME="你的项目名"

如果你的项目字段叫 MAIL_SMTP_PASS，那就写：

MAIL_SMTP_USER=你的Gmail邮箱@gmail.com
MAIL_SMTP_PASS=abcdefghijklmnop

不同项目字段名可能不一样，但本质一样：
SMTP 用户名填 Gmail 邮箱，SMTP 密码填应用专用密码。

Node.js 配置示例

如果你用 nodemailer，可以这样写：

const nodemailer = require("nodemailer");

const transporter = nodemailer.createTransport({
  host: "smtp.gmail.com",
  port: 587,
  secure: false,
  auth: {
    user: "你的Gmail邮箱@gmail.com",
    pass: "abcdefghijklmnop"
  }
});

也可以从 .env 读取：

MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USER=你的Gmail邮箱@gmail.com
MAIL_PASS=abcdefghijklmnop

PHP 原生项目配置示例

如果你的 PHP 项目需要 SMTP 发信，一般会有类似字段：

$mailHost = 'smtp.gmail.com';
$mailPort = 587;
$mailUser = '你的Gmail邮箱@gmail.com';
$mailPass = 'abcdefghijklmnop';
$mailSecure = 'tls';

$mailPass 这里填的依然是应用专用密码。

五、Gmail SMTP 常用参数

建议直接收藏下面这组配置。

SMTP服务器：smtp.gmail.com
端口：587
加密方式：TLS
用户名：你的 Gmail 邮箱
密码：Google 应用专用密码

如果使用 SSL，也可能是：

SMTP服务器：smtp.gmail.com
端口：465
加密方式：SSL
用户名：你的 Gmail 邮箱
密码：Google 应用专用密码

一般优先用：

587 + TLS

六、为什么我找不到“应用专用密码”？

这个问题很常见，通常是下面几种情况。

1. 两步验证没有开启

这是最常见原因。

没有开启两步验证，应用专用密码入口通常不会正常出现。

先去这里开启：

https://myaccount.google.com/security

找到：

两步验证

开启之后，再访问：

https://myaccount.google.com/apppasswords

2. 你用的是公司或学校账号

如果你的邮箱是这种形式：

xxx@公司域名.com
xxx@学校域名.edu

那它可能是 Google Workspace 账号。

这种账号的应用专用密码功能，可能被管理员关闭了。

这时你需要联系管理员，让他检查：

Google Workspace 管理后台 → 安全设置 → 应用专用密码

如果管理员不允许，你自己是开不了的。

3. 账号开启了更严格的安全保护

如果你的 Google 账号开启了高级保护计划，或者只允许某些更严格的登录方式，应用专用密码可能不可用。

这种情况下，要么改用 OAuth 登录授权，要么换一个允许 SMTP 应用密码的 Gmail 账号。

4. 你找错地方了

再强调一次：

应用专用密码不在 Gmail 设置里。

不要在这里找：

Gmail → 设置 → 查看所有设置

应该去这里：

Google账号 → 安全性 → 应用专用密码

或者直接访问：

https://myaccount.google.com/apppasswords

七、几个容易搞混的东西

Gmail 登录密码

这个是你平时登录 Gmail 的密码。

不要填到 MAIL_SMTP_PASS 里。

现在 Google 通常不允许你直接用登录密码做 SMTP 密码。

Google Authenticator 验证码

这个是 6 位动态验证码。

它只用于登录验证，不能当 SMTP 密码。

恢复代码

恢复代码是账号救急用的。

比如你手机丢了，验证器没了，可以用恢复代码找回账号访问权限。

它也不能用来发邮件。

应用专用密码

这个才是你要找的。

它是 16 位密码，只给 SMTP、邮件客户端、脚本程序这类应用使用。

八、配置好后怎么测试？

如果你是 Laravel 项目，配置完 .env 后，建议执行：

php artisan config:clear
php artisan cache:clear

然后再测试发送邮件。

如果是 Node.js 项目，改完 .env 后，重启服务。

如果是 PHP 项目，也要确认配置文件被重新加载。

九、常见报错排查

报错：Username and Password not accepted

大概率是密码错了。

检查这几项：

1. 是否填成 Gmail 登录密码了？
2. 是否复制错应用专用密码？
3. 是否保留了多余空格？
4. 是否用错 Gmail 邮箱？
5. 应用专用密码是否已经被撤销？

建议重新生成一个新的应用专用密码，再试一次。

报错：Connection timed out

这通常是服务器连不上 Gmail SMTP。

检查：

1. 服务器是否能访问 smtp.gmail.com
2. 端口 587 或 465 是否开放
3. 服务器防火墙是否拦截
4. 云服务器安全组是否放行
5. 服务器网络环境是否限制 Gmail

在某些服务器环境里，访问 Gmail SMTP 可能会受限。

报错：Could not authenticate

检查配置组合：

MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=你的Gmail邮箱@gmail.com
MAIL_PASSWORD=应用专用密码
MAIL_ENCRYPTION=tls

MAIL_USERNAME 和 MAIL_FROM_ADDRESS 最好先保持一致。

十、安全提醒

应用专用密码可以直接让程序用你的 Gmail 发邮件，所以不要随便发给别人。

尤其不要把它写进公开代码仓库。

错误示范：

把 .env 上传到 GitHub
把密码截图发到群里
把密码写进前端代码

正确做法：

放在服务器 .env 文件里
放在 CI/CD 的 Secret 变量里
放在环境变量管理器里
定期检查不用的应用密码并删除

如果怀疑泄露，马上进入应用专用密码页面，把旧密码删除，再生成新的。

十一、一句话总结

配置 Gmail 发邮件时，MAIL_SMTP_PASS 填的是 Google 账号生成的 16 位应用专用密码。

获取路径记住这个：

Google账号 → 安全性 → 两步验证 → 应用专用密码

最快入口：

https://myaccount.google.com/apppasswords

生成后，把 16 位密码填进项目配置里，就可以通过 Gmail SMTP 给别人发送邮件了。

每天claude code订阅版pro有多少token额度？

Fri, 08 May 2026 11:20:49 +0800

简短结论是：Claude Code Pro 套餐并没有"每天 token 数"这种额度——Anthropic 官方从来不按天计 token，而且也不公开具体 token 数。

实际的限额机制是这样的：

两层窗口：每 5 小时一个滚动会话窗口，再叠加一个每周上限。Pro 的会话额度每 5 小时重置一次；同时还有一个每周额度，从 session 开始 7 天后重置。

Pro 和 Code 共用同一个池子：Pro 和 Max 的额度在 Claude（网页/桌面/手机）和 Claude Code 之间共享，两边的活动一起计入同一份限额。所以你在 claude.ai 聊得多，Code 里能用的就少。

最近刚扩容：2026 年 5 月 6 日 Anthropic 和 SpaceX 签了算力协议后，Claude Code 在 Pro、Max、Team、Enterprise（按席位）套餐上的 5 小时窗口额度翻倍，同时取消了 Pro 和 Max 账户的"高峰时段"限速。也就是说现在的 Pro 比一周前能跑的活儿多了一倍左右。

为什么不给具体 token 数：因为同样的额度用 Opus 4.7 几把就烧完，用 Sonnet 4.6 能跑很久，再加上上下文长度、工具调用、缓存命中率都会影响消耗。Anthropic 官方建议在 Code 里用 /status 看剩余额度，用 /cost 看本次会话的消耗。

用完了怎么办：等 5 小时窗口重置，或者开 extra usage 按 API 价继续跑，或者升 Max 5x（一般是 Pro 的 5 倍额度）/Max 20x。

如果你想精确测自己每天能跑多少，最实在的办法是连着跑两三天，自己记录 /status 的消耗节奏——社区里 ccusage 这种第三方工具也能更细地拆开看。

忘记了自己的旧手机号，怎么安全找回？一篇讲透正规路径、检索方法和避坑思路

Thu, 07 May 2026 15:41:36 +0800

忘记了自己的旧手机号，怎么安全找回？一篇讲透正规路径、检索方法和避坑思路

很多人都遇到过这种情况：以前用过一个手机号，只记得开头和结尾，比如：

136******81

中间几位怎么也想不起来。

这个号码可能绑定过银行卡、邮箱、微信、支付宝、淘宝、学信网、旧简历、论文系统、招聘网站、论坛账号，甚至一些十几年前注册的平台。想找回来很正常，但这里面有一个重要前提：

找回自己的旧手机号，要走正规路径；不要通过公开互联网反查、拼接、撞库、购买数据等方式找。

手机号属于个人敏感信息。即使是你自己的号码，也不建议通过网上公开痕迹去“扒完整号码”。一是容易误伤隐私，二是可能搜到错误信息，三是有些方式本身就存在法律和安全风险。

真正靠谱的方法，是从运营商、官方查询、个人旧资料、旧账号绑定记录这几条线索入手。

一、先明确：你要找的是“完整号码”，不是随便猜一个号码

很多人只记得：

前三位：136；
后两位：81；
中间六位忘了；
大概知道曾经用过；
可能是自己实名办的；
也可能早已停机或销户。

这种情况下，千万不要靠猜。

手机号中间六位的组合数量非常大，即使你知道前后，也不能靠人工试出来。更重要的是，旧手机号如果已经销户，有可能被运营商重新放号给别人使用。你随便尝试登录、发验证码、拨打确认，可能会打扰到现在的号码使用者。

正确思路应该是：

先确认这个号码是否仍然与你本人身份有关，再通过官方渠道找明细。

二、第一步：用“一证通查”查自己名下电话卡

你可以先使用中国信通院的全国移动电话卡“一证通查”服务。

它的作用是：
通过你的身份证信息，查询你名下现在登记了多少张电话卡，以及涉及哪些运营商。

它通常不会直接把完整手机号全部展示给你，但它可以帮你判断：

你名下现在还有没有移动卡；
涉及中国移动、中国联通、中国电信、广电中的哪几家；
是否有异常办卡情况；
是否需要进一步去营业厅核查。

如果你记得旧号是 136 开头，那么大概率优先查中国移动。但不要完全排除其他情况，因为携号转网之后，号码归属运营商可能发生变化。

三、第二步：优先去中国移动营业厅查历史实名号码

136 号段历史上通常属于中国移动号段，所以你可以优先去中国移动。

最稳的方式是：

带本人身份证，去线下营业厅查询历史实名号码。

你可以这样问工作人员：

我以前实名办理过一个 136 开头、尾号 81 的手机号，现在不记得完整号码了。请问能否凭本人身份证查询我历史名下办理过、已销户或仍在网的号码记录？

注意，这里有几个关键词：

本人身份证；
历史名下办理过的号码；
已销户或仍在网；
136 开头、尾号 81。

有些线上客服权限有限，未必能查到历史销户记录。线下营业厅通常更适合处理这种问题。

如果中国移动查不到，再按顺序问：

中国联通；
中国电信；
中国广电。

尤其如果你曾经办过携号转网，或者中间换过运营商，单查一家可能不够。

四、第三步：从自己的旧邮箱里搜

邮箱是找回旧手机号的高命中率入口。

你可以登录自己以前常用的邮箱，比如：

QQ邮箱；
163邮箱；
126邮箱；
Gmail；
Outlook；
公司邮箱；
学校邮箱。

然后搜索这些关键词：

136
136 81
136****81
联系电话
手机号
手机号码
收货地址
报名信息
注册信息
验证码
简历
联系方式

如果你记得自己的名字，也可以组合搜索：

江天 136
江天 联系电话
江天 手机号
宁夏大学 江天 136
环境科学 江天 136

邮箱里最容易命中的内容包括：

旧简历；
招聘网站投递记录；
培训报名邮件；
考试报名确认；
电商订单；
快递通知；
论坛注册邮件；
老合同；
论文投稿系统；
学校系统通知；
支付平台安全提醒。

很多人找不回旧手机号，不是因为没有记录，而是没有系统搜过自己的邮箱。

五、第四步：查电商平台的历史收货地址

手机号最容易完整出现的地方之一，就是电商平台的收货地址。

你可以依次查看：

淘宝；
天猫；
京东；
拼多多；
苏宁；
当当；
唯品会；
美团；
饿了么；
携程；
飞猪；
12306。

重点不是看现在默认地址，而是看：

历史收货地址；
老订单详情；
售后记录；
发票信息；
退换货记录；
快递信息；
常用联系人。

有些平台现在为了隐私会隐藏手机号中间几位，但老订单、发票、售后记录里，可能还保留完整号码或部分号码。

你可以重点筛选：

2007年之后的订单；
早期淘宝订单；
老京东订单；
搬家前后的收货地址；
学校、公司、老家地址相关订单。

如果你只记得 136 开头和 81 结尾，可以在平台搜索框里尝试：

136
81
江天
宁夏
宜昌
长阳

六、第五步：查微信、支付宝、QQ、安全中心绑定记录

很多旧手机号都曾经绑定过社交和支付账号。

你可以检查这些地方：

1. 微信

查看路径大致是：

我 → 设置 → 账号与安全 → 手机号

如果现在绑定的不是旧号，也可以查看：

账号保护记录；
登录设备；
微信支付实名信息；
安全通知；
旧聊天记录中是否有人发过你的联系方式。

你还可以在微信聊天记录里搜：

136
手机号
电话
联系方式
收货地址

2. 支付宝

可以查：

账号与安全；
手机号；
登录记录；
账单；
收货地址；
转账备注；
生活缴费；
电子发票。

支付宝里经常能找到旧号码痕迹，尤其是收货地址、账单备注、身份认证记录。

3. QQ

如果你以前常用 QQ，可以查：

QQ安全中心；
密保手机；
QQ邮箱；
旧聊天记录；
QQ同步助手；
QQ空间留言；
旧群资料。

很多早期用户的手机号会出现在 QQ 资料、群名片、通讯录备份里。

七、第六步：查电脑、网盘、旧手机里的文件

旧手机号很可能藏在你的本地文件里。

重点查这些文件类型：

Word；
Excel；
PDF；
TXT；
简历；
报名表；
合同；
扫描件；
通讯录；
旧照片；
截图；
备份文件。

Mac 上可以这样搜

如果你用 Mac，可以打开终端，搜索文档和桌面里的 136：

grep -R "136" ~/Documents ~/Desktop 2>/dev/null

更精准一点：

grep -R "136.*81" ~/Documents ~/Desktop 2>/dev/null

如果你不熟悉命令行，也可以直接用 Finder 搜索：

136
手机号
联系方式
联系电话

Windows 上可以这样搜

Windows 可以用资源管理器搜索：

也可以用 Everything 这类本地搜索工具，搜索：

136
136 81
手机号
联系方式
联系电话

如果你有旧硬盘、旧U盘、旧电脑备份，也值得翻一下。很多早期简历和报名表里会留下完整手机号。

八、第七步：查旧简历、招聘网站和报名系统

手机号最常出现在简历里。

你可以重点登录：

智联招聘；
前程无忧；
Boss直聘；
拉勾；
猎聘；
领英；
个人博客后台；
老论坛账号；
学校就业系统；
各类培训报名系统。

搜索或查看：

我的简历；
历史投递；
附件简历；
账号设置；
联系方式；
报名表；
个人资料。

尤其是 Word 版简历、PDF 简历，往往保留完整手机号。

九、第八步：查云盘和相册截图

很多人会忽略一个地方：相册。

你可以在手机相册、iCloud、百度网盘、Google Photos、QQ空间相册里搜索或翻找：

验证码短信截图；
运营商短信截图；
快递短信截图；
订单截图；
简历截图；
报名成功截图；
证件扫描件；
银行预留手机号截图；
通讯录截图。

如果相册支持文字识别，可以直接搜索：

136
验证码
手机号
中国移动
10086
收货
联系电话

旧短信截图、快递截图和银行短信，命中率非常高。

十、第九步：查银行、证券、保险、社保、公积金等实名系统

如果这个手机号曾经长期使用过，大概率绑定过一些正式系统。

可以查：

银行App；
网银；
信用卡中心；
证券账户；
基金账户；
保险公司；
社保系统；
公积金系统；
个税App；
交管12123；
12306；
学信网；
学校教务系统；
医院挂号平台。

这些平台通常不会轻易展示完整旧手机号，但可以通过客服或线下网点确认历史预留手机号。

你可以这样问：

我以前可能用过一个 136 开头、尾号 81 的手机号作为预留手机。请问能否帮我核验历史预留手机号，或告诉我当前绑定信息是否与该号码有关？

注意，不要让客服直接透露敏感信息。你可以让对方通过身份验证后协助确认或变更。

十一、不要做这几件事

找旧手机号时，最容易走偏。以下方式不建议做：

1. 不要公开发帖求完整号码

比如：

我叫某某，曾经用过 136******81，谁能帮我查一下？

这种方式可能泄露更多个人信息，也容易被骗子盯上。

2. 不要购买所谓“社工库查询”

这类东西高度违法违规，数据来源也不可靠。即使查到了，也可能是过期、错误、他人信息。

3. 不要大量拨打疑似号码

你只知道前后几位，中间组合太多。盲目拨打会打扰别人，也没有效率。

4. 不要用验证码反复试登录

如果号码已经被别人使用，你反复触发验证码，会干扰对方，也可能导致平台风控。

5. 不要把身份证、姓名、学校、出生日期、旧手机号片段一起发到公开平台

这些信息组合起来，风险很高。

十二、推荐找回顺序

如果你想效率最高，可以按这个顺序来：

第一步：官方查名下号码

先用“一证通查”确认自己名下还有哪些电话卡。

第二步：中国移动营业厅

因为 136 开头优先考虑中国移动，带身份证去线下营业厅查历史实名号码。

第三步：邮箱搜索

搜：

136
136 81
联系电话
手机号
收货地址
简历

第四步：电商历史地址

查淘宝、京东、拼多多、12306、外卖、旅游平台。

第五步：本地文件和云盘

搜电脑、网盘、旧手机、旧硬盘里的 Word、Excel、PDF、截图。

第六步：旧简历和招聘网站

查所有历史简历、附件简历、投递记录。

第七步：银行、支付宝、微信、社保、公积金

通过实名验证，查历史绑定或预留手机号。

十三、可以直接复制使用的查询话术

问运营商

你好，我本人以前实名办理过一个 136 开头、尾号 81 的手机号，现在忘记完整号码了。请问能否凭本人身份证查询我名下历史办理过的号码，包括已销户和仍在网号码？

问学校或单位

你好，我想核对一下我以前在学校/单位登记的联系电话。我只记得号码是 136 开头、81 结尾，请问能否在本人身份核验后协助查询历史登记手机号？

问银行或平台客服

你好，我以前可能使用过一个 136 开头、尾号 81 的手机号作为预留手机。现在想核验历史绑定信息。请问在本人身份验证后，能否协助确认或更新预留手机号？

搜邮箱关键词

136
136 81
136******81
联系电话
手机号码
联系方式
收货地址
报名表
简历
验证码

搜电脑关键词

136
136.*81
手机号
联系方式
联系电话
收货地址
简历

十四、最后总结

忘记旧手机号，不要急着去公开互联网搜索，更不要试图通过非正规渠道反查完整号码。

真正靠谱的路径是：

官方一证通查 → 运营商线下营业厅 → 自己邮箱/电商/网盘/旧文件 → 银行和实名平台核验。

如果你只记得：

136******81

那就优先从中国移动开始查，再配合自己的邮箱、旧简历、电商收货地址和本地文件搜索。只要这个号码曾经长期使用过，大概率会在某个旧资料里留下痕迹。

找旧手机号，本质上不是“技术破解”，而是一次合法、系统、耐心的个人信息归档。走正规路径，既安全，也更容易找准。

应phone要求制作简历

Thu, 07 May 2026 10:56:37 +0800

我问：

context：

以下是我特别要好的高中同学给我推荐的职位，让我去试试。我是湖北宜昌的，跟老板是老乡，他是当阳市的，我是长阳县的，离的很近。

有一个宜昌老板的上市公司，招聘CAIO，200W，你有没有兴趣去聊聊呀？[偷笑]

东土科技

要求做过智能体开发，熟悉大模型，做的是AI转型

就是你现在讲课辅导的内容，哈哈

https://baike.weixin.qq.com/v10004530731.htm?fromType=liteappShare

还有我的博客：https://jiangtian.top，你应该能抓取到数据。

我的背景你应该也很清楚。自己没有正式做过管理岗，全是干活的小喽啰。在我们现在公司我也只能算是主力核心研发。但我是实战型。也就是啥都自己动手去操作。

我曾经参与过的项目有：南航管理平台，飞利信视频会议平台，智评云智能评估作业系统，天健督学视频系统，智评云智能核验系统，智评云大数据平台，内蒙古大数据管理局管理平台等。其中：智评云智能评估作业系统，天健督学视频系统，智评云智能核验系统，智评云大数据平台为主力研发。

兼职做过30+中小型系统，合育教育小程序，智学AI学习系统学生版、教师版，人人保障网系统（含后台管理、小程序、ios和安卓app），虚拟币交易撮合系统，恩施住建局图集管理系统等。

大约2年半时间，跟AI协作输出16000+篇内容，累计3000w+字，总阅读560w+。17个公众号推送累计850w+字。

写书三本，第一本代写，名为《SEO搜索引擎优化》，名字在我博客里有，给你也提过。第二本《互联网营销大全》，第三本未出版，名为《AI创作从入门到精通》，我将提供电子版。

毕业院校：宁夏大学。专业：环境科学。

工作经历：2007-2013，银川，心脑血管、饮水机等保健产品销售，做到兴庆区区域店长，年销售额最高到300万。

2013-2014，在家创业。

2014-2015，美丽站（北京）科技有限公司，SEO+全栈技术。

2015-2016，北京博威调查事务所，SEO+全栈技术。

2016-2017，新华频媒数据技术有限公司，SEO+全栈技术。

2017-2019，北京飞利信科技股份有限公司，后端研发，项目经理，兼职创业，项目名：智学AI，该项目的核心价值在于内置算法，采用艾宾浩斯遗忘曲线辅助K12阶段孩子学习（此处你可抓取同类竞品的介绍融入进来）。

2019-2026，北京智评云数字科技有限公司，股东，后端核心研发，项目经理，其间从2023年初AI正式火爆起来，深度使用AI进行技术研发、内容创作、openclaw及hermes技能skills测试应用、擅长使用claude code，codex，copilot等AI vibe coding软件。

2025-2026，兼职国泰道合AI实战导师，参与AI辅导授课、企业内训、AI项目落地。

第二个pdf是我的电子书，第三个截图是我博客后台截图。

出版书籍《SEO搜索引擎优化原理+方法+实战全网营销 SEM 搜索引擎优化》及《互联网营销实战宝典》两本。

https://product.dangdang.com/1520432875.html

https://product.dangdang.com/11173180505.html

还有制作智能体十数个，请你围绕我的兴趣列举3-5个，并作简要介绍。把为国泰道合制作的客户咨询整理入CRM算作一个智能体，将飞书里制作的提醒表单填写算作一个智能体，不过你需要包装的稍微高大上一点，将我为国泰道合正在开发的公众号选题也作为一个智能体介绍。昨天刚做的一个AI最新工具抓取聚合平台也作为一个智能体。还有经营竞对分析的也作为一个智能体介绍。简要介绍功能。还有八字排盘引擎。内容自动选题及发布智能体。

政治面貌为中共党员。同时笃信儒释道，颇有心得。

https://jiangtian.top/?id=5这个里面有简要介绍。

使用AI超过10000小时（GPT，CLAUDE，GEMINI，GROK，豆包，deepseek，GLM《智谱清言》）

在学校一直是学生干部，从学习委员到团支部书记等。

objective：输出一份高端商务版pdf简历。请你面向面试官编写这份简历，不要对着我说话。简历配色风格我第八份文件（图片）形式给你。每一页有页码。中英文双语吧。我的个人照片第七张第八张图。

style：风格严谨、不失活泼，体现我的专业度，同时传递出我的温暖。配色用我待会给你的图片。另外不要出现“不是。。。而是。。。”的句式，请把下面这段话改得更像真人写的，降低AI味儿。

要求：

1. 不要使用过度整齐的排比句；

2. 不要频繁使用“首先、其次、最后、总之”；

3. 不要用“不是……而是……”这种模板句；

4. 语气更自然，有轻微口语感，但不要太随便；

5. 保留原意，不要空泛拔高；

6. 多用具体表达，少用宏大抽象词。

tone：语气嘛！温柔大方，语言幽默，不是稳重，体现我修行人的气质、气场。

audience：东土科技人力资源部及高管层。

response：平常简历部分；我的自述部分，用半白话半文言写，全部配上中英文翻译；但不许花里胡哨；然后再抓取全网关于东土科技的核心信息，以彰显我对这家公司的了解以及我的认真度，尤其对创始人（我老乡）做细致信息搜集，并完成一篇“江楠观东土”的外部观察文章，提出对该公司AI落地的我的看法。
AI答：

【腾讯文档】江天_个人简历与作品集_A4图版_最终清晰版

https://docs.qq.com/pdf/DTGVqemJoVWhLaFJW

从身触入道

Thu, 07 May 2026 09:06:51 +0800

身触圆通这一脉，《楞严经》里讲得最清楚。你要找的那位菩萨，是跋陀婆罗（梵 Bhadrapāla，意译"贤护"）。

故事在《楞严经》卷五。佛问二十五位圣者各自从哪一根入道，跋陀婆罗带着同行的十六开士起座说：他们从前在威音王佛时出家，僧团按例去澡堂洗浴，他随例进去，水触身上的那一刻——"忽悟水因，既不洗尘，亦不洗体，中间安然，得无所有"。水不是来洗灰尘的，也不是来洗身体的，能洗所洗当下脱落，中间一段空空朗朗，没有"什么"可以指认。这一悟从威音王佛时就没忘掉，今生随释迦佛出家，证得无学。佛给他取的名字就叫跋陀婆罗。他自己下的判语是八个字：

妙触宣明，成佛子住。佛问圆通，如我所证，触因为上。

"触因为上"——这就是身触一脉的祖师印可，整个佛教史上靠触觉那一根直入而被佛亲自盖章的，就是他。

二十五圆通里，跟身相关的还有一位毕陵伽婆蹉，他从"身根"入。他出去乞食，被毒刺扎了脚，举身疼痛，他思惟"是谁在觉这个痛"——"虽觉觉痛，觉清净心，无痛痛觉"，由觉知反入，得阿罗汉。他下的判语是"纯觉遗身，斯为第一"。这一路偏在受蕴觉知，跟跋陀婆罗的"触尘"略有分工：一个是触境的当下能所脱落，一个是觉痛者反观谁在觉。你说身触跟你最相应，两路都该看，但若要认祖师，跋陀婆罗这一脉更正。

把经典开给你，由本及末。

一、根本经

《大佛顶首楞严经》卷五，二十五圆通章里跋陀婆罗自述那一段——命根所在，原文不长，要背下来。同卷毕陵伽婆蹉、月光童子（水大圆通）、乌刍瑟摩（火光三昧）、持地菩萨（地大圆通）几段也连着读，整张身心入道的图就完整了。
《般舟三昧经》（支娄迦谶译）。跋陀婆罗是这部经里的当机菩萨，整部经是他向佛请法。般舟三昧又叫"佛立三昧"，要求行人九十日经行，不坐不卧，全靠身体的极限维持心的专注——这是跋陀婆罗给后人留下的实修法门，仍然走身的那一根。慧远在庐山结白莲社修的就是这个。
《大方等大集经·贤护分》（阇那崛多译）。是《般舟三昧经》的另一个译本，更详尽。"贤护"就是跋陀婆罗的意译。
《大宝积经·贤护长者会第三十九》。讲跋陀婆罗作为长者居士的因缘，补他作为人的那一面背景。
《观佛三昧海经》卷九，里面有跋陀婆罗见佛三昧的记述。

二、辅证经

《大念处经》（南传《长部》第二十二经，对应北传《中阿含·念处经》）。佛亲口讲的身念处——观姿势、动作、呼吸、不净、四大、九想——是一切身入道法门的源头。跋陀婆罗的"妙触"是顿悟一闪，《大念处经》是把这一闪铺成二十四小时的日常功夫。两本对照读。
《佛说大安般守意经》（安世高译）及**《杂阿含·安那般那念经》**。呼吸出入触鼻端、触上唇——身触法门最稳当的入手处。
《维摩诘经·入不二法门品》。三十一位菩萨各说不二，其中善眼、善意几位从触的角度破能所，跟跋陀婆罗澡堂那一段可以互参。

三、祖师注疏（这一脉真正的修行说明书）

交光真鉴《楞严经正脉疏》——明代第一注，专立"舍识用根"一旨，对身根、触尘的入路讲得极透。
蕅益智旭《楞严经文句》《楞严经玄义》——把二十五圆通跟天台教观打通。
憨山德清《楞严通议》——憨山自己从耳根入，但讲身触一段也讲得很活。
圆瑛法师《楞严经讲义》——民国第一讲家，最适合当代人读，遇到不通的地方先翻这本。
宣化上人《楞严经浅释》——白话铺得最开，可以陪着原文一起念。

四、实修要诀（替你把跋陀婆罗那八个字翻成可下手的话）

"妙触宣明"四字，骨头在"宣明"二字。

水碰到身上的那一刻，多数人立刻分两段：一边是水（外面的尘），一边是身（里面的体），中间夹一个"我"在感觉。跋陀婆罗的悟就是这一刻没分。水来，身在，触是触，可是没有"水在洗我"这个故事。能所没立起来，所以"中间安然，得无所有"。

落到日常，做这几件事：

洗澡。 不要刷手机不要想事，让水从头浇下来，单独感觉那个触，不去命名它（"热""凉""舒服"都是命名）。每天一次，跋陀婆罗就是这样开的。
走路。 脚底每一次接触地面，知道触在那里，但不去分"地硬鞋软"。一开始走五分钟。
抚物。 喝茶时杯子在掌心的那个温度，握手时对方掌心的那个实在感，单独让它在那里几秒钟，不评论。
痛。这是毕陵伽婆蹉那一条路的入口。下次磕到桌角，不要立刻骂出来，停半秒，看那个痛在哪里、是谁在觉它。两路并修，互为印证。

久了你会发现，"触"从来没断过——身体每一刻都在触衣服、触椅子、触空气——只是平时被念头盖住没看见。这一根本来一直现成，跋陀婆罗只是替我们点了一下。

合十。