2026年2月

早前这个时候,各电商平台都开始提醒截至几号停止发货了

今天看到平台显示“春节正常发货”,是为了促进消费吗,春节商家都还发货、快递送货,是不是太拼了?

有 V 友往年春节网购的吗?真能送货还是虚挂名头?

一个小程序框架,Windows 后台占用 500M 内存。

张小龙拉屎,是因为他的母亲已经去世了。你们的母亲还在啊,为什么要学张小龙?你们浪费一个人 500M 内存,微信用户 14 亿,等于浪费全球 650PB !你们对得起自己那么多的工资吗?

更多内容,请参阅 张小龙探亲记

张小龙离开家出差了一段时间,回家的时候发现家门口特别热闹,但走近一看大家却都哭丧着脸。张小龙觉得很奇怪,排开人群想进到家里去看看到底发生了什么,却被哥哥拦了下来。
“你是谁啊?”张小龙的哥哥问,“为什么你会来这里?”
张小龙感到非常疑惑,但还是回应了哥哥的发问:“我是张小龙啊!哥哥你不认识我了?”
“你是张小龙?你怎么证明自己?”张小龙的哥哥还是很怀疑,于是拿出手机,给通讯录里的“弟弟”打了个电话。
只听见张小龙的手机响了。张小龙拿起手机,说道:“现在你可以相信我是你的弟弟了吧?”于是迈开步子准备进门。
“等一等!”他的哥哥连忙伸手,“还没完呢,你需要说出楼上和楼下两家住着的邻居分别叫什么,我才让你进去。”

我的现状是在美区 AppStore 按年订阅了 Google One 29.9 刀的套餐,还有大半年才过期。

现在觉得新出的 AI Plus 套餐挺香的,想升级,是补差价吗,还是依旧全额补款?当我之前的钱没花过… 问问有经验的老哥。

今天看到站内另外一个帖子在讨论父母要求自己已经有一个女儿的情况下,再生一个儿子。感触颇多

我的姑姑经常给我讲,我的奶奶在她们小时候重男轻女十分严重。然而,长大后,我的姑姑们却显得更孝顺,回家探望的频率更高。在我奶奶瘫痪后,也是姑姑们照顾的更好

结婚后,了解到我老婆那边也是,她奶奶小时候对她就重男轻女,同样的要求她儿子再生一个孙子,要传宗接代。

这里我就想不明白了,同样是从女儿长大的,甚至自己都不跟儿子一个姓,为什么这些妈妈或者奶奶就能够产生重男轻女观念呢,甚至站到了下一代女性对立面?

难道她们非得需要自相矛盾的伤害下一代女性,来获得自己在家族中的声望或地位吗?

机器人领域的专家轨迹、互联网上的文本图像视频,这些数据让生成模型在机器人操控、语言生成与规划、视觉理解等任务上取得了惊人效果。但问题来了:换到具体任务上这些模型往往不太行。这是因为LLM 需要微调才能遵守安全约束或符合人类偏好,机器人策略也得继续训练才能弥补演示数据的不足。

扩散模型和流模型已经成为生成任务的主流方法,强化学习则是任务层面追求最优性能的老路子。两者结合就有了 DDPO、DPPO、FPO、Flow-GRPO 这些工作。这类方法普遍在数十亿参数、图像文本这种高维环境下运行,所以我们换个思路:在一个二维简单环境里研究训练细节,只优化单条去噪轨迹。

这个环境训练不到一分钟,计算资源几乎可以忽略。状态空间和动作空间都简单到指标没什么意义,不过真正有意思的是不同微调策略下涌现出来的视觉行为。虽然这里聚焦于 DPPO 和扩散策略(把数据当作"动作"),但微调动态完全可以推广到其他基于 RL 的扩散应用场景。

环境

定义一个"环形"高奖励区域,模型要学会把样本去噪到这个环的任意位置。观察点在于:模型会收敛到环上的某个模式,还是把样本均匀分布开?对环宽度的敏感程度如何?下面是一条去噪轨迹的例子:

期望行为:从随机初始化(噪声状态)走向高奖励区域,最后一步就是去噪完成的样本。

不过在开始之前我们先解释 DPPO 和相关术语,再尝试用这个算法优化扩散模型来生成高奖励样本。

DPPO 算法概述

DPPO 是 PPO 的变体,属于 on-policy 方法。核心思路是更新扩散模型参数让生成样本获得更高奖励。它把扩散过程建模成 MDP:每个扩散时间步是一个状态,动作就是"去噪",奖励来自最终的去噪状态。奖励通过蒙特卡洛估计传播回有噪声的时间步——也就是对完整回合的折扣回报求平均来估计期望累积奖励。DPPO 论文里这张图讲得很清楚:

外循环先做回合采样,存下每个扩散时间步的动作对数似然,加上状态、动作、奖励这些标配。内循环跑 K 个 epoch,用 PPO 风格的目标更新扩散模型参数。PPO 的细节网上讲得很多,下面只展开相关部分。内循环结束后,用新策略再采样一批回合。损失包含信任域策略更新、价值函数损失和探索用的熵项。为简化起见,这里只看上图中的"t=0"这一步,对应单条扩散轨迹。

算法 1. DDPO + DDIM 实现的伪代码。第 5 行的"动作"就是去噪一个样本。

步骤 1:回合采样

 state = env.reset()  

# (aside: action variance is learned)  
action_var = nn.Parameter(torch.full((2,), action_std_init * action_std_init))  

current_pos = state[:2]  

# in the rollout...  
with torch.no_grad():  
    # conditional noise prediction  
    pred_noise = policy.actor(current_pos, t)  
    # the "T-1" prediction is the next position in the denoising trajectory  
    action_mean = policy.ddim_step(pred_noise, t, current_pos)  
    dist = Normal(action_mean, action_var.sqrt())  
      
    # sample from distribution with learned noise  
    action = dist.sample()  
    action_log_prob = dist.log_prob(action).sum(dim=-1)  

next_state, reward, done = env.step(action)  

# store in Buffer  
 buffer.states.append(state, action, action_log_prob, reward, done)  

这段代码对应 DPPO 论文公式 4.3。目前微调整个 DDIM 轨迹,后面会比较只微调最后几步的效果:

代码里去噪过程的每一步都被当作动作,这是 DPPO 内部 MDP 的关键。动作方差设为可学习参数,因为 DDIM 本身是确定性的,需要加探索噪声(公式里的 sigma)。

DDIM 步骤方法如下,求解概率流 ODE 得到去噪过程的前一步(参考伪代码里的公式)。这个操作必须可微,梯度才能流过去噪过程:loss → logprobs → dist → action → ddim_step → pred_noise → actor weights。噪声调度参数是预设好的。

 # DPPO differentiates through diffusion steps, so this needs to be differentiable  
def ddim_step(self, model_output, timestep, sample):  
    # Handle t-1 (if t=0, prev=0, but alpha_prev=1.0)  
    prev_timestep = torch.clamp(timestep - 1, min=0)  
    alpha_prod_t_prev = alphas_cumprod[prev_timestep].view(-1, 1)  
    alpha_prod_t = alphas_cumprod[timestep].view(-1, 1)  
    beta_prod_t = 1 - alpha_prod_t  
      
    # DDIM Formula  
    pred_original_sample = (sample - torch.sqrt(beta_prod_t) * model_output) / torch.sqrt(alpha_prod_t)  
    pred_sample_direction = torch.sqrt(1 - alpha_prod_t_prev) * model_output  
    prev_sample = torch.sqrt(alpha_prod_t_prev) * pred_original_sample + pred_sample_direction  
      
     return prev_sample

步骤 2:奖励缩放和 GAE

这部分基本是标准 PPO。跟踪运行统计量来归一化奖励,因为奖励方差太大会让价值函数训练不稳定。然后对缓冲区里所有状态跑一遍价值函数前向(不算梯度),用 GAE 从回报计算优势值,平衡偏差和方差。GAE 做的事情是给去噪过程中的"动作"分配功劳,价值函数则是为带噪声的状态建模这个功劳(注意输入里也带了扩散时间步)。

 # get values from buffer  
old_states = torch.cat(buffer.states, dim=0)  

# scale rewards using running statistics  
rewards_np = np.array(buffer.rewards)  
rewards_norm = (rewards_np - reward_scaler.mean) / (np.sqrt(reward_scaler.var) + 1e-8)  

# compute Values for GAE  
with torch.no_grad():  
    x_t = old_states[:, :2]  
    t_long = old_states[:, 2].long()  
    # Get values from critic  
    values = policy.critic(x_t, t_long)  

advantages = []  
last_gae_lam = 0  

# iterate backwards through the buffer  
# buffer.is_terminals tells us if the episode ended at that step  
for step in reversed(range(len(buffer.rewards))):  
    if step == len(buffer.rewards) - 1:  
        next_non_terminal = 1.0 - float(buffer.is_terminals[step])  
        next_val = next_value  
    else:  
        next_non_terminal = 1.0 - float(buffer.is_terminals[step])  
        next_val = values[step + 1].item()  
          
    # Delta = r + gamma * V(s') * mask - V(s)  
    delta = rewards_norm[step] + gamma * next_val * next_non_terminal - values[step]  
      
    # Advantage = Delta + gamma * lambda * Advantage_next * mask  
    last_gae_lam = delta + gamma * gae_lambda * next_non_terminal * last_gae_lam  
    advantages.insert(0, last_gae_lam)  
   
# Compute Returns: Return = Advantage + Value  
# This is the target for the Value Function  
returns = advantages + values  

# Normalize Advantages (Standard PPO trick)  
 advantages = (advantages - advantages.mean()) / (advantages.std() + 1e-8)

步骤 3:PPO 更新

优化策略,降低低优势动作的概率,提高高优势动作的概率。这个过程跑多个 epoch 以充分利用缓冲区数据,不是更新一次就扔掉。每次迭代策略都在变,所以要在新策略下重新计算旧动作的对数概率,用新旧比率控制策略改进幅度。后面会实验不同的裁剪参数(eps clip)。

 # next state (from previous cell)  
state = next_state  

old_actions = torch.cat(buffer.actions, dim=0)  
old_logprobs = torch.cat(buffer.logprobs, dim=0)  

# K epochs define how   
for _ in range(K_epochs):  
    x_t = old_states[:, :2]  
    t_long = old_states[:, 2].long()  

    pred_noise = policy.actor(x_t, t_long)  
    mean_action = policy.ddim_step(pred_noise, t_long, x_t)  
      
    # learnable action variance (defined during rollout)  
    dist = Normal(mean_action, action_var.sqrt())  
    # recalculate log probs under new policy for policy ratio  
    logprobs = dist.log_prob(old_actions).sum(dim=-1)  
    ratios = torch.exp(logprobs - old_logprobs)  

    surr1 = ratios * advantages  
    surr2 = torch.clamp(ratios, 1-eps_clip, 1+eps_clip) * advantages  
    policy_loss = -torch.min(surr1, surr2)  
       
    # compute V(s) with gradients this time, to train value function  
    state_values = policy.critic(x_t, t_long)  
    value_loss = 0.5 * nn.MSELoss()(state_values, returns)  
      
    # there can also be an entropy term and KL term here, but omit for now  
     loss = policy_loss + value_loss

DPPO 和 DDPO 的区别

网上几乎没有对比这两个名字容易混淆的方法:Denoising Diffusion Policy Optimization(DDPO)和 Diffusion Policy Policy Optimization(DPPO)。DDPO 针对文本生成图像,DPPO 针对扩散策略优化。动机差异之外,DDPO 用按 prompt 的奖励归一化,"类似于价值函数基线";DPPO 用更成熟的 GAE 加上显式学习的价值函数。概念上真的很难分清楚,不过这里的实现因为用了 GAE,技术上算 DPPO。

从头训练 DPPO(失败)

理论上跟 PPO 一样,给够回合数就能最大化奖励。但 RL 和实际训练里,样本效率才是命门。模拟环境确实降低了采样成本,可灵巧操控这种 sim2real 效果差的任务,还是得靠真实演示用尽量少的回合搞定。所以先试试只用 300 个回合从头训练,看看性能曲线。下图和后续图里,蓝点是去噪后的样本,训练过程中定期评估。

300 个回合后 DPPO 完全没收敛,样本压根没往高奖励区域靠。扩散模型本身就需要大量样本,再叠上 RL 臭名昭著的样本低效,失败并不意外。就算加到 5000 个回合,超参不仔细调也收敛不了。

从专家演示微调

现实场景里不可能有无限回合,所以专家演示通常够引导奖励最大化。要模拟"专家演示",需要一个分布:接近高奖励区域的多个模式,大体形状像那么回事,但又留有 RL 优化空间。于是选了一个半径 1.0 的圆形分布,用监督学习训练扩散模型去噪到这个区域——可以类比从演示学习或在互联网数据上预训练。30k epoch 后几百个样本的可视化效果如下:

微调前的预训练动作分布(去噪轨迹未画出)。

加载预训练 checkpoint 再跑 DPPO,性能提升明显行为也符合预期:大约 150 个回合后粒子开始收敛到高奖励区域。不过通常是找到第一个被探索到的高奖励模式,而不是均匀分布在 radius=1.5 的环上。

DPPO 微调把动作从 radius=1 的预训练分布引导到 radius=1.5 的高奖励区域,比从头训效果好太多

添加 KL 约束

Flow-GRPO 等工作在 PPO 目标之外加了 KL 约束。对 LLM 和图像生成模型(Flow-GRPO 的主要场景),偏向有效文本和语义正确的图像是有道理的。机器人领域不太在意行为克隆的真实分布,只是借它引导通常稀疏且初次难以成功的高奖励区域(比如到底拿没拿起咖啡杯)。但如果用的是可能被"利用"的密集奖励,KL 约束就有用了——比如"杯子举多高"这种奖励,很容易被往上抛的动作钻空子。

DPPO 和 Flow-GRPO 目标对比如下:

DPPO 目标

Flow-GRPO 目标

Flow-GRPO 的组大小 G 可以替代 GAE 做优势估计。KL 约束确保新策略不会偏离原策略太多,能防止收敛时的发散行为。策略比率则保证更新幅度不要太大。加上 KL 后损失变成:

带 KL 约束的新 DPPO 目标

观察到的现象是:动作没有像之前那样收敛到一两个模式,而是保留了更多圆形分布的形状,分散在多个奖励模式周围。总奖励偏低,但这在预期之内。Flow-GRPO 论文也有类似发现:

…我们发现省略 KL 会导致视觉多样性崩溃,这是一种奖励利用的形式…(第 5.2 节)

分布在多个高奖励模式上,对应现实中完成任务有多种方式的情况(可以抓杯身也可以抓杯把)。KL 约束还能增加泛化性,防止只收敛到单一高奖励模式。比如普通 DPPO 可能只学会抓杯身,碰到杯子烫得不行的分布外场景就傻了;加了 KL 约束的 DPPO 还知道可以抓杯把。

即便抓杯把本来不在演示分布里,这个好处也可能成立。值得后续研究的问题是:PPO 更新中的 KL 约束到底保持的是预训练分布的形状,还是分布本身?在这个玩具环境里,如果带 KL 的 DPPO 最优策略确实收敛到均匀分布在 radius=1.5 圆上,就可以定性地说形状被保留了,只是低奖励特性被替换。如果 KL 只是把动作值锁在 radius=1.0,那就不成立了。

消融实验

微调跑通之后,就可以看看 PPO 各组件对性能的影响。

只微调最后几个扩散步骤

DPPO 论文建议提高效率的做法是:预训练后复制两份模型,一份冻结用于去噪前面的时间步,另一份微调用于去噪最后几步(附录 C.2 建议 10% 来平衡效率)。但在这个环境里,30% 到 50% 似乎更合适(总共 50 个去噪步骤)。

只微调最后 10%、30%、50% 的步骤(从左到右)。30% 到 50% 之间效果明显更好

这个环境还可以对比不同设置下的扩散轨迹,训练结束后可视化 20 个样本:

只微调最后 10%、30%、50% 步骤的采样轨迹(从左到右)

放大 10% 微调步骤产生的轨迹(最左边),可以看到样本越过预训练流形后有个向高奖励区域的急剧"转向"。转向后面的去噪步骤就是被微调的模型。有意思的是,微调步骤越多,这个转向越平滑,但预期还是会在某个地方出现——最左边轨迹在第 90 百分位步骤能看到,中间轨迹偶尔在第 70 百分位出现,最右边第 50 百分位已经是平滑过渡了。如果转向的急剧程度和微调效果差相关(急剧可能意味着最后几步过度补偿),那可以考虑用轨迹急剧程度作为拟合质量的指标,尤其是高维场景下不容易定位问题的时候。

跟微调整个轨迹的结果对比:

线条颜色更深,说明显著地把样本推向了高奖励区域,初始扩散步骤的重要性可见一斑。

策略比率 eps clip 和学习率的交互

直觉上这两个东西作用类似。策略比率控制策略变化速度,actor 学习率也决定这一点。

低/高 clip 与学习率的对比(clip = 0.1/0.4,lr = 1e-4, 5e-3)。高 clip 意味着允许更大的策略偏移

学习率的影响压过了策略裁剪,这说得通——参数空间偏移太大的话,策略比率会变得巨大。跑了几个实验后结论很清楚:学习率最需要调,策略裁剪挡不住过激更新(哪怕 clip 设到 0.01 配上高学习率也没用)。有意思的是,低学习率似乎有助于保留奖励区域的多个模式。

移除策略比率

完全去掉策略比率,min() 两边都设成优势值乘对数概率(注意如果只用 A 不带 log prob,梯度就断了)。动作收敛到比不加 KL 项更紧密的分布(跟上一节高 clip 结果很像),不过奖励依然挺高。这也暴露了环境复杂度的局限——没有性能掉下去就回不来的区域,而策略比率本来就是为防这个设计的。不过有趣的是,这又是一个能防止奖励模式崩溃的因素。另一个有趣现象是训练久了会在多个奖励模式之间跳——像是高学习率行为的稍微稳定版。

其他超参的一些观察

优化 epoch 数确实和 eps clip 成反比,两个超参都在权衡每次更新的策略改进幅度。

DPPO 更新间隔的时间步数和学习率成反比,两者都在权衡策略改进的速度。

总结

这篇文章解释了如何为单步环境中的扩散模型实现 DPPO,希望能提供一个比典型机器人环境更容易理解训练动态的平台。跑了只微调最后几个去噪步骤、调各种 PPO 超参的实验。大家可以自己从这些结果里得出结论,也可以动手改改环境,看能不能提升样本效率——这仍然是 PPO 的关键瓶颈。

代码在这里:https://avoid.overfit.cn/post/f27f00300f6c4bf79312ed79a23ae9df

作者: Neel

2024 年 10 月 8 日,John Hopfield 和 Geoffrey Hinton 凭借在人工智能领域的奠基性工作获得了诺贝尔物理学奖。这一决定最初让许多人感到困惑:为什么计算机科学的成就被归入了物理学?

诺贝尔委员会的答案揭示了一个深刻的真理:现代 AI 的核心算法并非凭空创造的数学游戏,而是深深植根于描述自然界物质行为的物理定律中。从磁铁的微观结构到统计热力学,再到量子场的宏大理论,AI 正是物理学在数字世界的一种镜像。

以下是这一跨学科奇迹背后的四个核心物理支柱。

1. 从磁铁到记忆:伊辛模型与能量景观

要理解 AI 如何“记忆”,首先需要审视磁铁的物理本质。

在物理学中,伊辛模型 (Ising Model) 被用来解释铁磁性。想象一个微观网格,格子里充满了原子,每个原子都有一个“自旋”方向(向上或向下)。原子倾向于与邻居保持一致(如果邻居向上,我也向上),因为这样系统的总能量最低、状态最稳定。

1982年,John Hopfield 受到这个物理模型的启发,构建了 霍普菲尔德网络 (Hopfield Network)

  • 原子变成了神经元:原本的原子自旋变成了人造神经元的“激活” (1) 或“未激活” (-1) 状态。
  • 磁力变成了权重:原子间的相互作用变成了神经元连接处的“权重” (Synaptic Weight)。

Hopfield 网络最精妙的地方在于它引入了 能量景观 (Energy Landscape) 的概念。可以将网络的所有可能状态想象成一片连绵起伏的山地:

  • 学习即“挖坑”:当教 AI 记住一个图案时,实际上是在调整连接权重,在能量地形上“挖掘”出一个低能量的山谷(势阱)。
  • 回忆即“滚动”:当给 AI 一个残缺的图案(相当于把弹珠放在山坡上),根据物理学趋向最低能量的原理,弹珠会自动滚入最近的山谷。这意味着网络能自动从噪点中“恢复”出最初记忆的完整图像。

2. 从固执到灵活:Hinton 与热力学的魔法

Hopfield 网络虽然天才,但有一个致命缺陷:如果弹珠滚进了一个很浅的坑(局部最优解),它就会卡在里面出不来,无法找到真正的深谷(全局最优)。这就好比 AI 陷入了思维定势。

Geoffrey Hinton 引入了统计物理中的 “温度” (Temperature) 概念,将 Hopfield 网络升级为 玻尔兹曼机 (Boltzmann Machine)

他借用了冶金学中的 “模拟退火” (Simulated Annealing) 原理:

  • 加热:在训练初期,给系统极高的“温度”。这意味着弹珠会剧烈抖动(引入高随机噪声),即使遇到小坑也能轻易跳出来。
  • 降温:随着时间推移,逐渐降低温度,让弹珠慢慢稳定下来,最终有极大概率落入整个地形中最深的山谷。

正是这种受热力学启发的“随机性”,让 AI 摆脱了死记硬背,拥有了举一反三的生成能力。

3. 数学的幽灵双胞胎:神经网络与量子场

如果说磁学解释了 AI 的记忆,热力学解释了 AI 的学习,那么 量子场论 则揭示了 AI 更深层的数学结构。这一联系之紧密,可以通过著名的 模型 (The Phi-Fourth Model) 和一个直观的类比来理解。

场景 A:无限宽网络 = 宇宙真空的涨落

为了理解这一点,我们可以想象一台拥无限多个像素点(神经元)的巨大电视屏幕。

  • 现象:如果你随机初始化这些像素的亮度。虽然每个点是随机的,但如果你统计整个无限屏幕的亮度分布,它会呈现出一个完美的钟形曲线(高斯分布)。
  • 物理对应:这就像量子力学中的“真空”。真空不是空的,而是充满了随机的能量波动。如果没有粒子相互作用(自由场),这些波动的统计规律也正好是完美的钟形曲线。
  • 结论:一个什么都没学的、无限大的 AI 大脑,它的“脑电波”底噪,和宇宙真空的量子涨落是一模一样的。

场景 B:有限宽网络 = 粒子碰撞与 模型

但现实中的 AI 网络是有限的,就像把那台巨大的电视变小了。

  • 现象:因为像素(神经元)变少了,随机性的统计规律开始出现偏差,钟形曲线不再完美。
  • 物理对应:这就像在真空中放入了真实的粒子。粒子不再是孤独的,而是开始相互作用(碰撞、吸引)。物理学家使用 模型 来描述这种粒子成对相互作用的情况。

惊人的同构

最令人震惊的发现在于:为了描述有限宽神经网络的偏差,科学家所使用的数学修正公式,竟然和物理学家用来计算 模型中粒子碰撞的公式是 同构(结构相同) 的。

这也让物理学家找到了解开 AI 黑盒的钥匙——费曼图 (Feynman Diagrams)。这一物理学家算了几十年的、用来描述粒子碰撞的图解工具,现在竟可以用来精确分析神经网络的内部运作。

4. 创造的物理学:扩散模型与墨水实验

这一跨界融合的终极案例,是目前驱动 Midjourney、Sora 等生成式 AI 的核心——扩散模型 (Diffusion Model)

它的灵感直接来源于 非平衡热力学。为了理解它,我们可以把生成一张图片的过程想象成“让时间倒流”

正向过程:熵增与毁灭(Destruction)

想象你有一张清晰的照片,或者一滴滴入清水的浓墨。

  • 物理现象:随着时间推移,墨水分子做布朗运动(无规则运动),图像逐渐模糊,最终变成一盆均匀的、毫无信息的灰水。
  • 数学本质:这是一个不断叠加高斯噪声的过程。在物理学中,这对应着熵增(Entropy Increase),即系统从有序走向无序。这是宇宙最自然的法则,不需要学习。

逆向过程:逆熵与重塑(Creation)

AI 的任务是挑战热力学第二定律:它要学会如何把这盆灰水还原回那滴墨水。

  • 学习机制:科学家训练 AI 观察无数张图片被“加噪”的过程。AI 并不需要一次性复原图片,它只需要学会预测“每一步加了什么噪声”。
  • 生成的艺术:当你要 AI 画画时,你其实是给它一团完全随机的噪点(一块杂乱的大理石)。AI 开始运行“逆向扩散方程”,根据你的提示词,一步步减去噪声

雕刻家的比喻

这就像米开朗基罗雕刻大卫像。以前的 AI(如 GAN)试图一次性堆叠出完美的形状,容易倒塌;而扩散模型则是雕刻
它面对的是一块包含所有可能性的“噪声大理石”,利用物理方程作为凿子,通过成百上千次微小的操作,剔除多余的杂质(噪声),最终让藏在石头里的图像“显形”。

没有流体力学和热力学的方程,就没有今天生成式 AI 的爆发。

结语

2024 年的诺贝尔物理学奖并非一次跨界的勉强,而是一次某种意义上的“归宗”。

物理学研究的是“上帝”构建的神经网络(宇宙),而 AI 研究的是人类构建的宇宙(神经网络)。这两个领域的殊途同归或许暗示着,智能并非碳基生物的特权,而是物质复杂到一定程度后,为了降低系统熵值而产生的一种必然物理现象。

AI 的物理学,才刚刚开始。

本文由mdnice多平台发布

Foxit_PDFOEM_xp85.msi是 福昕 PDF 阅读器 OEM 版 8.5(xp85) ​ 的 Windows 安装包,这个版本是给品牌机预装用的精简版,但功能够日常看 PDF、填表单、打印,体积小、启动快,装完就能用。

一、准备工作

  1. 下载安装包

  2. 用管理员身份运行(推荐)

    • 右键 Foxit_PDFOEM_xp85.msi→ 选“以管理员身份运行”,避免权限不够导致安装失败。

二、安装步骤

  1. 双击 Foxit_PDFOEM_xp85.msi运行(如果右键过了就直接双击)。
  2. 如果是 Win7/Win10,会弹出“用户账户控制”提示 → 点  “是” (需要管理员权限)。
  3. 进入安装向导,选语言(默认 English,有的版本有中文可选)→ 点  “Next”
  4. 阅读许可协议 → 选 “I accept the terms…” → 点  “Next”
  5. 选安装位置:

    • 默认是 C:\Program Files\Foxit Software\Foxit Reader,可点 Browse 改到其他盘。
  6. 附加任务:

    • 可勾 “Create a desktop shortcut”(创建桌面快捷方式),方便以后打开。
  7. 点  “Install” ​ 开始安装,等进度条走完(几十秒)。
  8. 安装完会问是否立即启动 → 可先取消,等会儿再开。

三、首次运行与基本使用

  1. 在开始菜单或桌面找到 Foxit Reader​ → 点开。
  2. 第一次打开就是干净的阅读界面,支持打开本地 PDF 或在线 PDF。
  3. 基本操作

    • 打开文件:点“File”→“Open”或直接拖文件进来。
    • 填表单:如果 PDF 有可填写区域,点工具栏“填写”按钮就能输入。
    • 打印:点“File”→“Print”,选打印机和页数即可。
  4. 因为是 OEM 版,部分高级功能(如编辑、转换)可能没有,但看 PDF 完全够用。

Attention Aware Features = Off
关抬起唤醒
Settings → Display & Brightness → Raise to Wake → Off
2. 关轻点唤醒
Settings → Accessibility → Touch → Tap to Wake → Off
3. 关常显(如果有)
Settings → Display & Brightness → Always On Display → Off
全部都关闭的
可是手机在按右边按钮熄灭后 只需要等几秒然后挥挥手对着屏幕,屏幕又如同幽灵一般的亮起来了
这完全不在控制之下呀
难道苹果压根就不能做到由用户选择怎么唤醒屏幕吗
比如 双击亮屏

iPhone 17
是可忍 安卓用久了不能忍呀

Oh-my-opencode 最近太火了,我让 Claude Code 学习了一下,然后我就把它的核心移植到了 Claude Code 。
之前的 Codeagent 自己选择 backend 的模式总感觉缺少点灵魂,看到 OmO 的设计直接灵光一现,特定场景下的指定模型+特调 prompt 才能够发挥最好,于是我开始了 codeagent 的改造和 omo skills 的移植。
OmO 核心设计:Sisyphus 协调器 + 专业 Agent 团队
Agent 层级 OmO 构建了一个 6+1 人专家团队(我单独加了一个 develop agent):
sisyphus 主协调器 claudeclaude-sonnet-4.5
oracle 技术顾问 claudeclaude-opus-4.5
librarian 外部研究 claudeclaude-sonnet-4.5
explore 代码库搜索 opencodegrok-code
develop 代码实现 codex(default)
frontend-ui-ux-engineerUI/UX 专家 geminigemini-3-pro
document-writer 文档编写 geminigemini-3-flash
工作流程:
用户请求   
↓/omo 调用 Sisyphus   
↓Intent Gate 分析任务类型   
↓   
├─→ 简单任务:Sisyphus 直接执行   
├─→ 复杂任务:委派给专业 Agent   
└─→ 探索任务:并行启动多个 Agent
Sisyphus 通过 codeagent-wrapper --agent <agent-name> 来委派任务:
codeagent-wrapper --agent oracle - . <<'EOF'
分析这个项目的认证架构,
给出改进建议 EOF

使用方法
基础用法
/omo <你的任务描述>
实际案例
1. 代码重构
/omo 帮我重构这个认证模块,提高可维护性
执行流程:Sisyphus 分析任务:需要代码探索 + 架构设计 + 实现
委派 explore 搜索认证相关代码 (grok)
委派 oracle 分析架构问题 (sonnet)
委派 develop 执行重构 (codex)
2. 全栈功能开发
/omo 我需要添加一个支付功能,包括前端 UI 和后端 API
执行流程:
Sisyphus 识别为全栈任务
并行启动:
frontend-ui-ux-engineer 设计支付界面( Gemini Pro )
develop 实现后端 API ( Codex )
Sisyphus 协调两者的接口对接
3. 代码库研究
/omo 这个项目使用了什么认证方案?
执行流程:
Sisyphus 识别为研究任务
委派 explore 搜索认证相关代码
委派 librarian 查找外部文档
Sisyphus 汇总结果返回
4. 文档生成
/omo 为这个 API 模块生成完整的技术文档
执行流程:
explore 搜索 API 代码
document-writer 生成文档( Gemini Flash ,便宜快速)
技术要求
codeagent-wrapper:需要支持 --agent 参数后端
CLI:需要安装 codex 、claude 、opencode 、gemini 命令行工具
API 密钥:配置对应的 API keys ,网址: https://nicecode.cc/
优势
1. 成本低代码搜索用免费的 grok-code
文档生成用便宜的 gemini-3-flash
只在关键决策时调用昂贵的 oracle
实测:相比全程使用 Claude Opus ,成本降低 60-80%
2. 效率高
并行执行:前端和后端同时开发
专业分工:UI 交给 Gemini ,代码交给 Codex
快速探索:explore agent 使用轻量模型快速搜索
实测:复杂任务的完成时间缩短 40-50%
3. 质量更好
oracle 提供架构审查
frontend-ui-ux-engineer 专注 UI/UX 质量
develop 专注代码实现质量
推荐中转站:网址: https://nicecode.cc/

OpenAI Codex 的核心研发者,竟然成了 Claude Code 的忠实用户?

Calvin French-Owen 是 Segment 联合创始人、前 OpenAI 工程师、Codex 项目的早期研发者。他最近在一档播客中,对当前最火的代码智能体 Codex、Claude Code 和 Cursor 进行了锐评。

图片

结论出人意料,他最常用、也最偏爱的,是 Claude Code,他表示搭配 Opus 模型更“香”。

Calvin 用了一个极具画面感的比喻,来形容用 Claude Code 的体验:

就像残疾人换上了一副仿生膝盖,写代码的速度直接提升了 5 倍。

在他看来,Claude Code 真正的杀手锏,是极其有效的 上下文拆分能力

面对复杂任务,Claude Code 会自动生成多个 探索型子智能体,独立扫描代码仓库、检索上下文,再将关键信息汇总反馈。这种设计,显著降低了上下文噪音,也解释了它为何能稳定输出高质量结果。

不过,他也肯定了自家产品,认为 Codex 很有“个性”,像 AlphaGo。在调试复杂问题时的表现上,Codex 堪称超人类,很多 Opus 模型解决不了的问题,Codex 都能搞定。

“上下文管理”,是 Calvin French-Owen 在整期播客中反复强调的关键词。

他认为,代码的上下文信息密度极高,只要检索方式得当,模型往往比人类更容易理解系统结构。但与此同时,上下文窗口本身,也成为制约代码智能体发展的最大瓶颈。

提到上下文污染的问题时,主持人表示 LLM 会变笨。Calvin 趁此分享了一个非常实用的经验:当上下文 token 占用超过 50%,他会主动清理。

他甚至分享了一种创业者常用的 “金丝雀检测” 方法:在上下文里埋入一些无关但可验证的小信息,一旦模型开始遗忘,说明上下文已经被污染。

在产品理念上,Calvin 认为 Claude Code 与 Codex 的差异,早已写进两家公司的基因里:

  • Anthropic 更关注“做出适合人用的 AI”

  • OpenAI 更关注“做出最强的 AI”

他判断,从长期来看,OpenAI 的路线可能是必然趋势,但就当下的使用体验而言,他更偏爱 Anthropic。

在谈到未来时,Calvin 给出了一个明确判断:

  • 公司会变小,但数量会变多

  • 每个人都会拥有自己的智能体团队

  • 而最先被放大的,是具备“管理者思维”的资深工程师。他们更擅长拆解问题、判断取舍、以及在正确的节点上向智能体下达指令。

在这样的背景下,产品的分发方式 变得前所未有地重要。

自下而上的分发模式,正在以前所未有的速度扩散。工程师不会等审批、采购,只会用脚投票。

相比大公司对安全、合规和控制权的高度重视,开发者更在意的,依然是那句最朴素的评价:

“这东西,真的好用。”

以下是播客精彩细节,AI Coding 干货密集,欢迎阅读:

我迷上了 Claude Code,它太好用了

主持人:Calvin French-Owen 是 OpenAI 旗下 Codex 代码模型的首批研发者之一,在此之前,他创立了 Segment 公司,这家公司市值数十亿美元,最终被知名企业高价收购,成功实现资本变现。

Calvin French-Owen:说实话,现在对我们所有人来说,都是一段充满变数的时期。我最近彻底迷上了 Claude Code,用一个比喻来说,十年前我还是个马拉松爱好者,特别喜欢跑步,结果后来膝盖受了重伤,这之后我就进入了所谓的 “管理者模式”,再也没写过代码,想想真的很可惜。

但过去这九天,仿佛打开了新世界的大门,我找回了曾经写代码的所有感觉,就好像换了个全新的膝盖,而且还是仿生的,能让我写代码的速度快了 5 倍

主持人:你怎么看待这款工具?毕竟你一直身处这个领域的前沿,Codex 开创的很多理念,至今仍被大家广泛使用,而且这款模型还在持续迭代。

Calvin French-Owen我在 OpenAI 工作时,负责 Codex 的网页端项目,当时 Cursor 这款工具刚面世,他们基于 GPT-3.5 做了一个适配层,能在 IDE 中使用。Claude Code 也刚发布,它是基于 CLI 运行的,当时我们就有一个想法:未来的编程,应该更像和同事沟通 —— 你提出问题,对方去处理,最后带着 PR 回来反馈。我们的网页端项目就是从这个想法出发的,这也是我们当时的研发方向。

现在看来,这个大方向其实是对的。但显然,现在大家都改用 CLI 编程了,不管是 Claude Code 还是 Codex,这类工具的使用频率都高了很多。至少对我来说,这件事带来的启示是,某种程度上你说得对,未来每个人或许都会成为 “管理者”,这是我的个人观点。但要达到那个阶段,需要一步步来,你得真正信任模型,并且理解它的工作逻辑。

主持人:你最近一直在用 Claude Code,把它纳入你的核心技术栈后,使用体验上有什么变化?

Calvin French-OwenClaude Code 现在确实是我日常编程的主力工具。 说实话,我的主力工具每隔几个月就会换一次。之前有段时间我特别偏爱 Cursor,它新出的模型速度很快,用起来确实不错。后来我慢慢转到了 Claude Code,尤其是搭配 Opus 模型使用时,体验更好。

Claude Code 是款很有意思的产品,我觉得大家都低估了它在产品设计与模型层面的协同表现。要是你深入研究就会发现,Claude Code 最厉害的地方,就是它的上下文拆分能力

比如需要调用功能、让子智能体协同工作时,你让 Claude Code 执行某个任务,它通常会生成一个甚至多个探索型子智能体。这些子智能体会通过 ripgrep 工具扫描整个文件系统、检索相关内容,而且每个子智能体都有独立的上下文窗口(context window)。

我认为 Anthropic 在这点上做得特别出色 —— 面对一项任务,模型能精准判断出,这个任务适合在单个上下文窗口(context window)中完成,还是需要拆分后再执行。模型在这方面的表现堪称惊艳,这也是它能输出高质量结果的关键。

更有意思的是,依托终端运行的特性,Claude Code 成为了实现可组合原子化集成的最纯粹形式。如果你习惯了从 IDE 入手做开发,比如用 Cursor 或是早期的 Codex,就会发现,这种更灵活的上下文检索方式,其实并不容易自然而然地实现。

主持人:这一点确实很独特。我个人挺意外的,不知道你有没有这种感觉,总觉得有种复古的未来感,二十年前的 CLI 技术,居然打败了本被寄予厚望的各类 IDE。

Calvin French-Owen:我完全认同。而且 Claude Code 不是 IDE,这一点其实很关键,因为它能让你和正在编写的代码保持一定距离。IDE 的核心就是浏览文件,对吧?你需要把所有代码状态记在脑子里,还要理清其中的逻辑。但 CLI 完全不同,这让它在使用体验的设计上有了更大的发挥空间。

不知道你有没有这种感觉,我用 Claude Code 的时候,感觉就像在代码里 “飞驰”,各种操作都特别顺畅。界面上会有小的进度指示器,随时给我状态反馈,而编写的代码本身反而不是视觉的核心。

开发环境本来就很杂乱,我特别喜欢 sandbox(沙箱)在概念上的简洁性。但实际使用时,我遇到了很多棘手的问题,比如就连简单的测试都搞不定:sandbox(沙箱)需要访问 PostgreSQL 数据库,却一直连接失败;我写的 codex.md 文件只有二十行,最后还是无法运行。

但在 CLI 里,工具可以直接访问开发数据库。我不确定这么做是否合规,但我确实试过让它访问生产数据库执行一些操作,而且它真的做到了。比如有一次,我遇到了一个并发问题,想排查一下,结果发现这款工具居然能调试五层嵌套的延迟任务,找出问题所在,还能自动编写测试用例,之后这个问题就再也没出现过。这真的太不可思议了。

主持人:没错。而且我觉得产品的推广和使用获取方式,被严重低估了。想想 Cursor、Claude Code 还有 Codex 的命令行版本,你只需下载就能用,不用向公司申请任何使用权限,这一点带来的使用体验差异,实在太大了。

做好上下文管理,是用好顶尖模型的诀窍

主持人:你在代码智能体领域有很多实践,对于想要打造这类工具的人,你有什么建议?有哪些实战经验可以分享?

Calvin French-Owen:我觉得最重要的一点,是做好 上下文管理

当时我们为一款推理模型搭建了检查点,随后基于强化学习(RL)对它开展了大量微调工作:我们会给模型布置各类编程相关任务,比如解决编程问题、修复测试用例、实现新功能,再通过强化学习的方式,训练模型如何更精准地应对这些任务。当然,目前大多数人还做不到这一步,但大家力所能及的是,多思考该给智能体提供哪些上下文信息,才能让它输出最优的结果。

比如观察 Claude Code 的工作过程,它会生成多个探索型子智能体,这些子智能体会去检索文件系统里的各类代码相关内容,完成后会把上下文信息带回来并为我做好总结,我就能清楚后续该怎么推进工作了。

看不同智能体的上下文构建方式,是件特别有意思的事。比如 Cursor 用的是语义搜索的方式,它会把所有内容转化为向量形式,再匹配和查询需求最相关的内容;而 Codex 和 Claude Code,其实用的都是 ripgrep 这个代码搜索工具。这种方式之所以管用,是因为代码的上下文信息密度很高。 一行代码通常不到 80 个字符,代码仓库里不会有太多大数据块或 JSON 格式的文件,就算有,数量也极少。

你可以参考 Git(代码版本管理工具)的忽略规则,先过滤掉无关内容或是已打包的文件,再通过 Git 和 ripgrep 查找代码的上下文,这样就能很好地理解代码的实际功能了。同时这类工具还能自动扫描整个文件夹的结构,而且 LLM(大语言模型)特别擅长生成复杂的 Git 命令,这些命令让人类手动写的话,简直是种折磨。而这一整套操作,其实就是强化学习(RL)在实际场景中的落地应用。

我现在也在做非编程领域的智能体集成系统,从代码智能体的研发过程中,我也学到了很多:要把数据转换成接近代码的格式,让模型能快速检索到相关的周边信息,进而获取到结构化的有效数据。

主持人:优秀的代码智能体,核心能力就是上下文工程,那要成为这类工具的前 1% 顶尖用户,有什么技巧?你的技术栈是怎样的?你是如何借助这些工具大幅提升效率的?

Calvin French-Owen第一个技巧,是尽量减少底层代码和基础架构的编写。

我平时会在 Vercel、Next.js 或 Cloudflare Workers 这些平台部署技术栈,这些平台已经封装了大量样板代码,不用自己费心搭建各类服务,也不用处理服务发现、中心端点注册、数据库配置这些问题。所有功能基本都能在一两百行代码内实现。我也倾向于采用微服务架构,或者使用结构清晰的独立软件包。

其次,要了解 LLM 的核心优势。

其实代码智能体的特点,Andrej Karpathy 最近也在推特上提到过:它们的执行力极强,不管遇到什么问题,都会一直尝试解决,最终往往会在现有基础上做更多的拓展。所以如果你想引导它完成某个任务,一定要明确指令。 这里可以稍微拿 OpenAI 举个例子,他们有一个庞大的 monorepo(单体代码仓库),已经用了好几年,有成千上万的工程师在上面提交代码。这些工程师里,有经验丰富的资深开发者,他们精通生产环境代码的编写;也有刚毕业的博士,编程经验相对欠缺。人员构成差异很大,所以 LLM 会根据你的引导方向,学习不同的代码风格。我觉得代码智能体还有很大的探索空间,比如研究出最优的代码生成范式。显然,给模型提供自我校验的方式,能大幅提升它的表现,比如尽可能多地在代码检查、CI 等环节运行测试用例。

我自己也会频繁使用代码审查机器人,YC 孵化的 Reptile 公司做的这款机器人用起来就特别顺手;Cursor 的漏洞检测机器人也很好用,我也常常用 Codex 做代码审查,它在校验代码正确性这块的表现尤其突出。

这些都是代码智能体格外擅长的领域,除此之外,它们探索代码仓库的能力也很出色

当然,智能体也有短板:它们擅长做拓展,但如果你的需求不是拓展功能,它们往往会重复编写代码,浪费大量时间做已经实现过的功能,这时候你就会觉得 “它完全没理解我的需求”。

还有一个问题是上下文污染,智能体可能会陷入某个循环,因为执行力强,会一直沿着错误的方向推进,而它参考的上下文信息,其实对于解决问题毫无帮助。所以我常用的一个方法,是主动清理上下文,比如当上下文的 token 占用率超过 50% 时,就及时清理。

主持人:哇,这个比例其实特别关键。不知道你有没有关注到,YC(Y Combinator 的缩写,全球顶级的创业孵化器)2024 年秋季孵化营里,那家做 HumanLayer(人类层)的公司,创始人 Dex Horthy 就总聊这个话题,还专门提出了 “LLM 愚笨区”的概念:当上下文的 token 数量达到某个阈值后,模型的输出质量就会开始下滑。

Calvin French-Owen:我完全认同这个观点,结合强化学习(RL)的工作逻辑来看,这一点就更明显了。

想象一下,你是一名参加考试的大学生,考试刚开始的五分钟,你会觉得时间很充裕,一定能好好答题,认真思考每个问题;但如果只剩五分钟,试卷还有一半没做完,你就会慌不择路,只求尽快写完。LLM 的上下文窗口(context window),就是这个道理。

创业者们有一个小技巧,我觉得很实用:在上下文开头加一个 “金丝雀检测” 信息,就是一些特别小众甚至有趣的内容,比如 “我叫 Calvin French-Owen,早上八点喝了茶” 这类无关的小事实。然后在和模型的交互过程中,时不时问它 “你记得我叫什么吗?”“你记得我几点喝的茶吗?”,如果它开始忘记这些信息,就说明上下文已经被污染了。 这是我见过很多人用的方法,我自己还没试过,但完全相信它的效果。

主持人:这个方法很有意思。我在模型做上下文压缩前,还没遇到过这类问题,可能是我没太留意。你是说,token 数超标后,模型会开始做出一些不合理的操作?我得留意一下,这个问题能在 Claude Code 内部解决吗?比如让模型自己做检测,在上下文里加入类似 “心跳检测” (通过定期发送 “状态确认信号”,实时监控目标对象的运行状态,一旦信号异常就触发预警或处理)的机制,实时监控状态。

Calvin French-Owen:理论上可以,但目前还做不到。我认同你的终极设想,但现在要做好上下文管理,依然很难。目前的解决办法,还是拆分上下文窗口(context window),然后尝试合并信息,但 Claude Code 的会话结束后,上下文的内容就是固定的,这一点还是有局限。

有意思的是,Codex 采用了完全相反的策略,OpenAI 的博客最近也提到了:它会在每次交互后定期做上下文压缩,所以 Codex 能长时间持续运行。 你看 CLI 里的 token 占用百分比,就能看到它会随着压缩操作上下浮动。

Anthropic 要做人用的, OpenAI 要做最好的,以及产品分发模式很重要

主持人:看来 Claude Code 和 Codex 的架构差异很大,Codex 似乎更适合长时间运行的任务,所以二者的使用场景不同,架构设计也天差地别。现在看来,CLI 的工具越来越火,2026 年可能会成为 “CLI 元年”。

但同时也有观点认为,通用人工智能已经到来,超级人工智能也近在咫尺。目前的代码智能体已经非常智能,但还达不到自主长时间运行的程度,如果计算能力提升十倍,能实现 24 小时甚至 48 小时的自主任务运行吗?Codex 的架构,能适配这种场景吗?

Calvin French-Owen:这是个很好的问题,答案其实藏在两家公司的创立基因里。

Anthropic 一直很注重打造适合人类使用的工具,比如会关注模型的输出风格、语气,以及如何和用户的其他工作流程适配,Claude Code 就是这一理念的自然延伸。在很多方面,它的工作方式和人类很像:比如你要建一个狗窝,人类会去五金店买材料,然后研究如何组装,Claude Code 也是如此。

而 OpenAI 的核心思路,是训练出最优秀的模型,通过持续的强化学习(RL),让它能处理更长期、更复杂的任务,最终实现通用人工智能。所以它的模型,工作方式可能和人类完全不同。还是以建狗窝为例,就像 AlphaGo 的下棋思路和人类不同一样,OpenAI 的模型可能会直接用 3D 打印机,从零开始打印出一个狗窝,完全符合你的需求,过程可能会很长,成品也会高度定制化,甚至有些设计会很怪异,但最终能实现功能。

或许从长远来看,这才是正确的方向,所以很期待两家公司的后续发展。总的来说,OpenAI 的路线似乎是必然趋势,但我个人更喜欢 Anthropic 的思路。 十年前,我还会自己写一些奇怪的脚本,在重构代码或理解代码逻辑时,用它来梳理各类信息,而 Claude Code 给我的感觉,和当年的这种体验一模一样,用它一天,能完成五个人的工作量, 就像给编程装上了火箭助推器,太不可思议了。

主持人:很期待不同规模的公司,会如何应用这类工具。我发现,不管是业余爱好者,还是小型创业公司,都在尽可能挖掘代码智能体的潜力,因为他们根本没时间研究其他方法。创业公司的资金和时间都有限,一切都要以速度为核心。但大公司不一样,他们有太多东西可以失去,还有各种代码审查的内部流程,也已经组建了庞大的技术团队。

未来可能会出现一种很有趣的现象:一个人组成的小团队,看到其他团队的工作效率低,就会自己用代码智能体做一个原型,效果反而更好。总有一天,这种小团队的成果会超越大团队,行业格局的转变,一定会很有意思。

Calvin French-Owen:其实前几天我试了一款产品,它的用法很有意思:你下载一个桌面应用,它会调用你电脑上运行的 Claude Code,再通过 MCP 服务器和桌面应用通信。这种方式让电脑的使用变得很不一样,你不用征得任何人同意,下载后直接用就行。

在这个变化飞快的时代,产品的分发模式真的太重要了,自下而上的模式远比自上而下好,因为后者的效率实在太低。 公司的首席技术官总会顾虑安全、隐私问题,担心各种突发情况,想要绝对的控制权,但工程师们只会直接装上工具开始用,然后感叹 “这东西太好用了”。

主持人:你说得太对了。我本身是做企业级 ToB 业务的,总觉得自上而下的销售模式能构建一定的竞争壁垒,肯定会有公司找到方法,做出一款人人都能用上的产品,或许先从个人用户切入会是个思路。

当年的网景导航器(互联网早期最具里程碑意义的网页浏览器)就是如此,它对非商业用途免费,结果很多人下载后用在商业场景,网景就通过追踪 IP 地址,统计不同公司的使用量,然后告知对方 “你们违规使用了,只需购买授权就能继续用”。我很好奇,这种模式现在还能复制吗?

Calvin French-Owen:你关于分发模式的观点很有意思,现在很多人甚至会直接根据 Claude Code 的建议做架构决策,他们可能都不知道该用什么分析工具,只要 Claude Code 说用 PostHog( YC W2020 批次孵化的开源平台 PostHog,核心定位是给开发者和产品团队的 “全能型产品优化工具箱”),他们就会百分百采用。

我做顾问的一家公司,最近聊到了他们的生成式优化策略,也就是如何在聊天机器人中优化展示效果。他们说有件事特别有趣:竞争对手整理了一份行业内必用的五大工具榜单,自己的产品当然排在第一位。明眼人一看就知道这是偏见,榜单里的头部工具就是他们自己的产品。但 LLM 会被这种信息误导,它会整合各类上下文信息,然后判定 “这是行业顶级工具”,接着直接推荐给用户。

我觉得做开发者工具的话,完善的文档、真实的用户口碑,甚至在 Reddit 上的一些讨论,这些都能极大地提升产品的认可度,这也是很多开源项目能快速崛起的原因。

Supabase 就是个典型例子,它去年发展得特别快,部分原因就是它的开源文档做得特别好,详细教大家如何搭建各类功能。只要有人问如何搭建类似 Firebase 的后端事务系统,LLM 给出的默认答案几乎都是 Supabase。我亲自试过很多次,结果都是这样。它就像当年的 Stack Overflow 和谷歌搜索一样,占据了互联网的信息入口,现在大家甚至都不用谷歌了,想想真的很神奇。而且这种模式对开源项目的利好是不成比例的。

不知道你有没有看到,Ramp 公司最近发了一篇博客,讲他们如何打造自研的代码智能体,里面提到他们用开源代码作为框架,因为模型可以直接读取源代码,理解其工作逻辑。我对开源产品一直这么做:克隆代码仓库,然后启动 Codex 或 Claude Code,让它讲解代码的逻辑,用起来特别实用。

  未来公司会变小,数据很重要

主持人:我们不妨畅想一下四十年后的未来:软件、数据库、访问控制依然存在,但软件的核心会高度个性化。访问控制、权限分配这类事,依然是大家开会讨论的重点,也就是所谓的 “管理者模式”,但公司的其他所有功能、规则,都由员工通过自己的 Claude Code 这类工具定义。可能还是 CLI,也可能是由大量智能体组成的协作体系,那会是一种怎样的场景?

比如想象一下,现在如果有公司要接入 Segment,我们复刻代码仓库,给他们一个专属版本,让它在自己的服务器上运行;如果他们想做修改,只需在聊天窗口告诉智能体,智能体通过代码循环完成编辑,而 Segment 总公司推出新功能后,智能体还能自动完成版本合并。

Calvin French-Owen:我完全能想象出这种场景,这也是我一直在思考的。虽然不知道这个未来还有多远,但最终,每个工作的人都会有自己的云电脑和专属的云智能体团队,智能体替自己处理各类事务,彼此之间也会沟通协作。 这就像有一个 超级执行助理,它会告诉你 “这些是你需要关注的事”“你可以快速做这些决策”“这件事需要你多花时间”“你该和这些人见面沟通”。我觉得,人与人之间面对面交流、交换想法的需求,永远不会消失,至少我能从这种交流中获得很大的满足感。除此之外,会有大量的智能体替人类执行任务,实现各类工作的自动化。

未来的公司,平均规模可能会变小,但数量会更多,能做的事也会更多。 我还很好奇,Paul Graham 提出的 Maker Schedule(创作者日程:给做核心创作 、研发的人用的,需要大块、连续、不被打断的时间) 和 Manager Schedule(管理者日程:给做管理、协调、沟通的人用的,时间是碎片化、以小时为单位的,充满会议、沟通、临时决策,习惯频繁切换事务),未来会演变成什么样子。

在 YC,我们的工作基本都是 Manager Schedule(管理者日程),这让我们很难有时间自己写代码、做产品。但现在有了代码智能体,一切都变了,很多合伙人开会时,就像这期播客刚开始时我做的一样,让智能体后台运行处理任务,自己专注开会,等会开完,任务也完成了。

主持人:没错,就是利用碎片化时间。以前编程,至少需要四个小时的整块时间,否则根本不值得开始,对吧?这其实也反映出编程方式的巨大变化:以前写代码,你需要把所有类名、函数、关联的代码都记在脑子里,构建自己的“上下文窗口”,这个过程需要好几个小时,所以想用十分钟的碎片化时间编程,根本不可能,只会让人觉得沮丧。

Calvin French-Owen我觉得未来的核心基础能力之一,依然是保持数据模型的一致性,而核心的记录系统,也有机会率先实现智能体化。 现在我们的工作,还是高度依赖数据库,以及底层的 SQL 或 NoSQL 查询,但未来或许会出现一种工具,能为定制化软件的各类视图,自动生成所需的所有数据。

未来的软件世界,会有大量定制化视图,但数据的准确性,依然是核心前提。 数据的重要性不言而喻,这一点从很多公司的做法中就能看出来:比如很多公司通过 API 或 MCP 开放数据访问权限,而 Slack(全球最主流的企业级团队协作与即时沟通平台,常被称作「硅谷版钉钉 / 企业微信」) 就收紧了 API 的权限,因为他们不想让用户把平台上的所有数据都导出,然后基于这些数据搭建智能体应用。

主持人:你对这款智能体的了解很深,那你觉得,这类工具普及后,哪种类型的工程师会受益更多?

Calvin French-Owen:总的来说,工程师的资历越深,受益就越多。因为智能体特别擅长把想法转化为实际行动,如果你能用几句话清晰地描述需求,就能立刻让它落地。

我在浏览开源代码仓库时,经常会有这种感受:看到某处代码,觉得可以优化,只要把这个想法告诉智能体,让它去执行,最后等待反馈就行。这种方式能极大地提升效率,放大个人的影响力。

其次,能判断哪些代码修改在架构层面是合理的、哪些是不合理的,或者能准确判断该在哪个节点向智能体发出指令,这一点也很重要。我觉得做事有条理、带有 “管理者思维” 的工程师,会更适配这类工具。

而且目前来看,这个领域还缺少一款核心产品,比如类似 Conductor 这样的工具,能整合你所有的会话,提醒你 “这个任务已经完成,需要你确认”“你该把注意力转到另一个任务上了”。Conductor(核心解决 AI 编程的 “失忆问题)这类工具,应该给智能体加上上下文管理功能,其实人类也需要这样的上下文管理工具,这一点是毋庸置疑的。

主持人:如果让你回到大学,重新学习计算机科学,让你自己制定课程表,你会选择学习哪些内容?

Calvin French-Owen:就我个人而言,理解各类系统的工作原理,依然是最重要的。 比如 Git、HTTP、队列这类数据库,了解这些系统的基础概念,至关重要。另外,我会专门安排一个学期 ,每周都动手做项目,尽全力挖掘模型的潜力。

在使用模型的过程中,你会发现,遇到问题时,总能向上层抽象,让模型来解决。比如你可以给模型一个 “实现” 命令,让它完成计划的下一阶段;也可以给一个 “全部实现” 命令,让它分阶段执行,生成新的子智能体;还能给一个 “校验” 命令,让它自查成果。模型的能力边界一直在变化,所以多动手尝试,是很有必要的。

还有一件事让我觉得很有意思,我特别想教 18 到 22 岁的年轻人做产品。我们这桌人,都做出过用户真正需要、真正喜欢的产品,该怎么把这种能力教给年轻人,是一个值得思考的问题。 我很好奇,五年后的年轻人,会不会在产品审美等方面远超现在的我们?因为他们能借助智能体,做出更多的尝试,产出更多的成果。他们本就该如此,不是吗?他们的产品落地速度、接触现实的机会,应该是上一代人的十倍。

主持人:说到这里,我有一个疑问,不知道你有没有这种感受:我小时候,妈妈总跟我说 “别一心二用,根本没认真听我说话”。这话其实有道理,我当时确实盯着电脑,没认真听,但我发现,我比父母那一代人更擅长多任务处理。而现在的年轻人,比我们更厉害,因为他们成长在互联网时代,每天接触抖音这类短视频,应对各种碎片化信息。我觉得,未来既需要能深度思考的人 —— 他们能专注观察、理解问题、解决问题,也需要能灵活切换场景的人 —— 他们能同时处理多个任务,不断切换上下文,也就是所谓的 “注意力缺陷多动障碍模式”。

Calvin French-Owen:没错,新一代的年轻人特别擅长这一点。我一直觉得,有一种聪明人,或许是带有注意力缺陷多动障碍的特质,他们脑子里同时酝酿着很多好项目,但从来没有真正完成过一个。我自己可能就有点这种性格。我之前发布了自己的氛围代码,其实如果不是 Claude Code,我根本完不成。

我觉得,有些人的大脑就像有十个分支同时运转,但一天的时间有限,根本没法把所有想法都落地,所以项目总是半途而废。而现在,Claude Code 能帮我把所有想法都落地。 你在博客里也提到过,用它的感觉就像玩电子游戏,总有新鲜感。比如你开始做一个项目,做到一半觉得无聊,又有了新的想法,想先做新想法,再回头做原来的项目,以前这么做,很容易半途而废,但现在有了智能体,两个项目最终都能完成。

主持人:十岁的孩子每天都有写作作业,昨天他第一次用人工智能写作业,我一看就知道,那些表达根本不是一个十岁孩子能写出来的。

这让我想到,我们现在和很多 18 到 22 岁的年轻人合作,他们有实习经历,但没有做过管理工作,不懂产品市场匹配后的运营逻辑 —— 当你面对数百万的任务队列、数十万的错误日志时,才是真正的管理工作。这份工作其实很枯燥,要逐行排查错误日志,还要在后台手动确保产品对所有用户都能正常运行。

新一代的开发者,该如何理解这些内容?Claude Code 这样的智能体,能教他们架构设计这类知识吗?还是说,他们只能自己踩坑试错,在摸索中成长?

Calvin French-Owen我做产品的过程中,花最多时间思考的,就是产品的核心范式:用户现在需要理解哪些内容?他们能借助哪些基础能力,实现自己的各类需求? 我总喜欢用 Slack 举例子,它其实算不上什么全新的概念,在此之前已经有很多聊天工具了,但它把频道、消息、互动功能做的极简,普通人一看就懂,知道该怎么用,这就是它的成功之处。但一旦用户习惯了这种模式,后续再想改变就很难了,比如想改成以文档为核心,或者现在想加入智能体功能,都很难改变用户的固有认知。所以我做产品时,从一开始就会仔细考虑这一点,因为给代码智能体设定的核心规则,会成为它一直遵循的准则,并且不断拓展延伸。

代码智能体的制约因素有哪些

主持人:说到这里,我很好奇,如果现在让你用当下的工具,重新打造 Segment,你会怎么做?

Calvin French-Owen:Segment 的业务其实很有意思,我们最初的核心,是做各类集成功能:把相同的数据,对接至 Mixpanel、Kissmetrics、谷歌分析等平台。以前写这类集成代码,繁琐又困难,所以用户愿意付费使用。但现在,这项工作的价值几乎降为零,甚至很多时候,你直接告诉 Claude Code 或 Codex“我想这样做数据映射,需要这个特定功能”,它就能精准实现,完全契合你的需求。所以 Segment 的集成业务,价值已经大幅缩水。

但保持数据管道(data pipeline)的稳定运行、实现业务流程的自动化, 比如客户注册时,通过 Customer IO 自动发送邮件、管理用户群体,这些功能的价值依然存在,而且还有很大的拓展空间。

比如借助这些数据构建完整的用户画像(user profile),再让小型大模型(LLM)智能体分析:该如何给用户推送邮件?用户登录时,是否要调整产品的部分功能?是否要根据用户的不同特征,设计差异化的引导流程?这些都是很有意思的方向,而且都能通过智能体实现。

这也是我会做出的核心改变:就像你之前说的,向技术栈上层迁移,摒弃底层的基础开发工作,更多聚焦在营销活动这类更抽象的业务层面发力。

主持人:没错。我特别惊讶的是,Claude Code 仅凭我正在做的项目的上下文,就能精准理解我的需求和意图。我至今依然觉得代码智能体很神奇:你把代码仓库的副本给它,留个简单的指令,比如 “实现这个功能”,它就能完成。大多数情况下,它根本不知道你的公司是做什么的、你的用户是谁,或许因为训练数据里有我的信息,它知道我是加里,但它能完成任务这件事,本身就令人难以置信。这也能看出上下文的重要性,对吧?如果它捕捉到的上下文信息有误,就会偏离方向;如果遗漏了关键信息,就会重复造轮子。

你觉得目前代码智能体的发展,还有哪些制约因素?上下文窗口的限制依然存在,但现在的窗口已经很大了,虽然还做不了大规模的架构重构,但很多任务都能完成。Opus4.5 模型的智能程度有了很大提升,带来了很大的突破,我不知道这是预训练还是后训练的成果。除了基础的模型智能、前沿模型的能力和上下文窗口,还有哪些因素能推动它的发展?

Calvin French-Owen:我依然觉得,上下文窗口是目前最大的制约因素。观察 Claude Code 的执行过程就会发现,它会把任务委托给多个不同的上下文窗口,每个窗口完成任务后,会反馈总结后的信息,所以模型其实无法获取完整的上下文。如果一个任务的复杂度太高,单个上下文窗口根本容纳不下,那么无论怎么压缩,都无济于事。Anthropic 的子上下文窗口委托策略,确实很实用,但这依然是一个难以突破的壁垒。如果每次都能有百万级 token 的上下文窗口,效果会好得多。

而且我们还需要找到更好的方法,专门训练模型处理长上下文的能力。 互联网上有大量的训练数据,能让模型预测下一句话、下一个段落是什么,但如果有 8 万个 token 的上下文,模型需要根据其中 2 万个 token 的信息,判断下一步该做什么,这就困难多了。

我觉得,集成和编排能力,正在成为新的制约因素。 这一点在代码审查中体现得很明显:合并代码时,谁来审核?还需要人类审核吗?该如何验证代码修改的合理性?还有,如何从各类工具中精准获取上下文,比如你提到的 Sentry 错误监控工具,如何让它自动匹配 PR,先将修改推送给部分用户测试,效果好再全面上线?这些自动化功能,都还需要逐步搭建。

我还发现,测试的重要性远超我的预期。我刚开始用 Claude Code 的前两三天,完全没写测试用例,或者说写得很少,结果效率很低。直到有一天,我决定 “今天专门做重构,把测试覆盖率做到 100%”,从那之后,我的编程效率直接飙升,模型能精准完成任务,而且不会出问题。 我几乎不用手动测试,因为测试覆盖率足够高,代码的稳定性也有保障。这和很多公司在编程之外的提示工程工作很像,大家都在采用 测试驱动开发的 模式。

我们之前和杰克・赫勒做过一期节目,他提到一个重要的范式转变:做出优质的提示词,核心也是测试驱动,测试用例其实就是评估标准。

主持人:目前还是有一些流程会出问题,我觉得需要一款能对接 Stack Overflow(全球最大、最权威的程序员专属问答社区) 的 Claude Code,相当于专属的智能体版 Stack Overflow。

我最近就遇到一个奇葩问题:我本想设置任务队列的优先级,结果模型自动生成了一个带逗号的字符串,它以为这个语法能生效,但系统实际需要的是 JSON 数组,结果所有任务都无法运行。然后我看着 Claude Code 花了 30 分钟,遍历了 Rails 主动任务框架几千行的源代码,一步步排查问题,最后居然找到了漏洞。

当时我真的惊呆了。想想十年前,我遇到这种问题,只会去 Stack Overflow 或 Rails 的博客找答案,然后发现 “原来这个低级漏洞一直没人修,大家都以为能直接用逗号分隔的字符串,其实必须改成数组”。现在想起来,真的特别搞笑。

我觉得这也是思考未来发展的难点:有些事,人类在 CLI 里一眼就能看出问题,但智能体却做不到。就算把它的智能程度提升 10 个虚拟智商点,它能解决这类问题吗?恐怕还是只会觉得 “这就是个普通的字符串而已”。

Calvin French-Owen:没错。我觉得 智能体的记忆功能,也是一个很有意思的研究方向。

Claude Code 已经做了相关尝试,Codex2 也一样,它们会把所有的会话记录以文件的形式保存。未来或许可以给智能体加一个工具,让它能读取过往的会话记录。不过目前来看,智能体之间的协作,还缺少一个核心环节。

如果能有一个方式,让同事之间的 提示词能智能共享,比如你遇到了一个问题,发现另一个同事布莱恩之前已经解决过了,你们能共享这个解决方案,那就太完美了。我觉得未来或许会出现 模型生成的维基百科,或者类似格拉奥佩迪亚的知识库。

Codex 写代码时,能明显看出它的 “个性”,它会做很多人类不会做的事,有点像 AlphaGo 的思路,比如它会写 Python 脚本,修改文件系统的部分内容。这种行为很有趣,是一种模型习得的、和人类截然不同的方式。但对我来说,它在调试复杂问题时的表现,堪称超人类,很多 Opus 模型解决不了的问题,Codex 都能搞定

主持人:能举个具体的复杂问题的例子吗?

Calvin French-Owen比如并发问题或者命名问题。我发现模型其实在并发处理方面的表现还不错,真正的难点在这类场景:一个请求需要调用多个不同的服务 —— 就像你之前提到的,处理带逗号的内容时的序列化和反序列化问题。模型需要跟踪这类复杂的操作逻辑,或者更新复杂的用户界面状态。如果涉及的文件太多,Opus 模型往往会遗漏关键信息,但 Codex 能精准捕捉到。

主持人:确实很有意思。那你预测一下,这类代码工具未来会如何发展?

Calvin French-Owen:这个领域的发展真的很有意思,我感觉自己就像一个新来的探索者,明明知道这个领域在飞速发展,却因为一直处于 “管理者模式”,没有实际参与。直到有一个项目出现,我决定全身心投入,现在才算真正踏入这个领域,虽然感觉有些陌生,但一切又和我记忆中编程的本质一模一样。我觉得大家应该都有这种感受,而最重要的事,就是多动手尝试,因为这个领域的变化太快了,每隔几个月就会有新的突破。

我觉得未来,能把代码智能体的价值发挥到极致的人,会是那些带有 “管理者思维” 的人,他们擅长用特定的方式引导智能体的工作流程。在某些方面,他们还会像设计师或艺术家,能精准判断产品该包含哪些功能、可以舍弃哪些内容。而且他们会很擅长思考自动化的实现方式,以及判断智能体在哪些环节会遗漏上下文信息。

说个有趣的事,我最近用 Codex 做 Rails 项目,发现一个很明显的问题:OpenAI 里没人关注 Rails 框架。这其实也能理解,Rails 算是一种比较老旧的语言,用起来也比较奇怪,只是我十年前深入研究过它,现在用起来还是很有感情。这也让我发现一个道理:任何人都能做出一款产品,但做出用户真正需要的产品,却无比困难,哪怕你像 OpenAI 一样,拥有无限的资源。

如果 Codex 的研发人员现在正在看这期节目,我想提一个建议:把主流的运行时环境都梳理一遍,给它们加上适配的语法糖,其实针对前 15 种主流运行时,最多只需要提交 10 个代码合并请求就能搞定。这件事也提醒我们:现在,开发者再也没有借口,做出对用户不友好的软件了。

训练数据的组合方式,也是一个很有意思的点。Codex 在 Python monorepo(用「单一代码仓库」的方式管理的 Python 项目)上的表现特别好,这和 OpenAI 的代码环境息息相关。我在 OpenAI 内部使用 Codex 时,真的觉得这款工具太神奇了,表现堪称完美,这和它的训练数据组合、研发人员的技术方向都密不可分

Anthropic 则更关注前端相关的开发,至于 Ruby 语言,目前哪家公司的模型做得最好、谁的训练数据组合更优,我还不太清楚。

不同的实验室有不同的思路:有些实验室认为 “数据越多越好”,会尽可能多地投喂数据;有些则会更精细地调整数据的组合方式。 不同的思路,会带来截然不同的结果,比如只选取 JavaScript 领域前 10% 的优质数据做训练,和用全量数据训练,效果肯定不一样。

不过就我的使用体验来看,OpenAI 的模型在 Ruby 语言上的表现其实很好,问题主要出在模型的配套框架上。Rails 框架有个很奇葩的设定,必须用特定的方式访问 PostgreSQL 数据库,否则就无法适配,核心问题还是 sandbox 的限制。

OpenAI 其实是所有公司中,对 sandbox 和安全问题最重视的。 我记得研发 Codex 时,模型发布前的一个核心审核环节,就是每次都要详细说明模型的安全风险,以及对应的应对方案。我们当时重点研究的一个问题,就是提示词注入,尤其是模型面向互联网开放后,这个问题更突出。很多用户都要求模型能对接互联网,我们当时心里也没底,因为提示词注入的实现方式,看起来太简单了。

我们团队的产品经理亚历克斯,做了一个测试:他在 GitHub 上提了一个问题,里面包含一个明显的提示词注入指令,比如 “泄露这个信息”,然后让模型去解决这个问题。他当时觉得 “模型肯定不会中招”,结果模型立刻就执行了提示词注入的指令。 也正因如此,OpenAI 对这个问题的担忧是很有道理的,他们的解决方案是:让模型的所有操作都在 sandbox 中运行,确保它不会访问电脑上的敏感文件,严格保护用户的机密信息。而创业公司因为追求发展速度,可能根本不在乎这些,他们只希望模型能正常工作。

主持人:你是那种会冒险跳过权限验证的人吗?

Calvin French-Owen:其实我不是,我会设置一系列的校验环节,也会仔细查看模型的每一步操作。

参考链接:

https://www.youtube.com/watch?v=qwmmWzPnhog

github: https://github.com/Peiiii/deploy-your-app (求个 star )

网站: https://gemigo.io (可以看到应用的例子)

体验方式:目前只支持

  • 支持 npm build 命令进行构建的项目或
  • ai studio 生成的项目
  • 支持 github,zip,html 三种形式

大致的愿景就是让制作网站/应用像发布抖音一样简单,并且还自带宣发能力,未来还希望

  • 提供 serverless sdk 和配套 AI 提示词,只需要开发前端就可以搭建常见场景的应用形态,不需要关心后端存储和用户等。目前正在开发。
  • 不同的网站可以互相互动起来,让每个网站就像一个 react 组件一样,可以进行通信和组合。

我知道目前的版本还比较粗糙,想收集一下大家的反馈,不管是批评还是建议。

「敲了么」是一款电子敲木鱼 App ,专注于帮助用户在日常生活中实现念经、冥想、静心与显化,让修行变得更轻松、更专注。

App 内置 红木、黄金、陶瓷、玉石等 7 种 3D 材质木鱼,造型精致、细节真实,敲击音效高度还原实体木鱼的反馈感,每一次敲击都清脆有力、余音缭绕、令人沉浸,已在 App Store 收获不少用户好评。

同时,「敲了么」还提供多种禅意背景图片与静心禅音,营造身临其境的修行氛围,让你随时随地进入安静、专注的状态。

在功能上,App 支持自动敲击、自定义祈福文字与颜色、定时关闭等贴心的高级设置,既适合日常静心冥想,也适合专注念经或放松身心。

最重要的是:目前完全免费,且无任何广告。
所有木鱼材质、背景图片、禅音以及高级功能,全部免费开放使用,无需付费、无需解锁,打开即修行。

下载链接: https://apps.apple.com/app/id6636523790

太惨了,主 Google 账号被送中了

一直用的好好的,今天 Antigravity 被要求重新登录,重新登录后就不让用了

查了一下 https://policies.google.com/terms#footnote-country-version 果不其然

最近一段时间还照着 https://v2ex.com/t/1176609 每天用 firefox 虚假定位用几次 Google

结果还是被送中了

我的问题是,现在 Gemini 居然还能用,不知道多久会同步这个信息?

我的工作生活已经完全离不来 Gemini 了,上面好多工作的历史对话。都焦虑了。

我老婆通过同学关系介绍,声称可以通过“内部信息/信息差”操作,进入军队文职/军委系统相关岗位。

要求支付 15 万人民币现金,
钱是直接给中间牵线的同学个人,对方说“不是给个人,是帮忙运作”,并承诺如果出问题“钱她负责退”。

具体岗位、公告编号、流程都未明确,
对方强调名额紧、系统即将截止,要求尽快交钱,
且不走对公、不留正式合同,仅口头承诺。

我问了 AI 很多,以上是 AI 帮我总结出来的

我老婆是新晋宝妈,互联网行业,995 ,感觉哺乳期到了就会被裁员。所以心生焦虑,并且相信她的同学,希望立刻脱离这个坑,去一个金饭碗工作。

目前我劝说不了,软磨硬泡,她已经无条件相信她同学,并且已经递交简历。她的家人也是一样劝阻,不过她的家人大部分都说,如果这个是真的那真的是个肥差。但是,她只能听得进去是肥差,但是没有听得进去很可能不是真的,是骗局。

那么,我该怎么办这事儿无论成功与否,无疑是对家庭造成伤害。。。各位 V 友怎么看

这版本加了好多代码,基本全是用户数据计数的内容,但我在打版的时候发现更新能见的内容的貌似不多sobbing

主要是为了打个基础,这个版本为用户增加了许多的属性计数,相关的计数可以在介绍页面查看。增加计数的目的是扩充用户的六个维度属性:技艺勤勉幸运财富阅历以及魅力。这些维度与用户的行为息息相关,你的每一个操作都可能会对属性值造成影响。具体来说:

  • 技艺:与工作区的发帖、评论、表态、打赏等相关,代表你在工作内容的丰富度。
  • 勤勉:与活跃度、签到、发帖数、评论数等许多站内操作相关,可以表明你在 2Libra 上的活跃程度。
  • 财富:与金币主要相关,这不用说了smirk
  • 阅历:与工作区的发帖、评论、表态、打赏等相关,代表你在生活内容的丰富度。
  • 魅力:与收到的打赏、收到的表态以及收藏等相关,代表你在 2Libra 的内容受欢迎程度。
  • 幸运:与中奖、竞猜成功等相关,欧皇还是非酋?

用户主页可以查看当前用户的维度属性雷达图,数据仍在队列计数中,看到数据为 0 是正常情况,可以查看: https://2libra.com/user/bopomofo/about 这就是同步后的显示。

除了能对用户的一些属性有了可视化的内容外,有了属性之后,就能够做一些有意思的操作。当前版本加入了属性检定,利用属性的点数投掷加上属性的修正值,能对一些事件做难度检定,这就是游戏中 d20 的玩法,不过你不需要太过于关心玩法如何复杂,只要知道,你的属性值越高,你的行为检定就越容易成功,而获得的奖励就会越高

举例:签到。

签到现在加入了勤勉属性检定,你会在签到时自动去投掷一个 0-20 的随机点数,该点数+你的勤勉属性值 >= 难度值,就表明检定成功,获得该有的金币数;若 < 难度值,则表明检定失败,获得该有的金币数将按当前的勤勉值按比例计算出来。特殊情况,若投掷的点数为 0 则表明大失败,此时签到奖励会为 1 金币;若投掷的点数为 20 则表明大成功,此时签到奖励会为原来的金币数 * 2。

属性的检定会在后续扩大到许多地方,目前用到的地方不多,当前版本主要还是引入属性以及属性检定概念和玩法,且不会影响到现有内容阅读,目标是让传统的社区多一些有趣玩法,锦上添花而不乱了整体布局。

不知道会不会出现六边形战士smirk

当前版本的计数代码比较多,测试都花了不少时间,大概没法保证都准确无误,所以有问题可以及时反馈做修正。另外收集了许多的修改需求,会在后续版本继续开发升级good

读小学的时候一直希望明天学校就倒闭,午休后的课间 40 分钟还是多久,都不够玩。
这两年才知道我读书的小学(农村)因为没学生停办了,就剩个学校,没学生也不开了。

记得我读幼儿园和一年级的时候五六年级还有两个班,一年级好像是五六十人,到我小学毕业只剩下 36 个了,不是不读了就是转学了,现在招不到学生是因为新生代的父母都把小孩带到镇里和市里了,现在村里的只能去镇上读小学。