家里的宽带上行是 150Mbps ,使用 iKuai 软路由测速 150M 正常,手机连接硬路由 AP WIFI 使用 speedtest 等测速正常,NAS 跑 PT ,上传速度正常,能跑满 150M ,有公网 IPV6 ,NAS 部署 iperf 在外网通过移动 5G IPV6 测速,下载只有 5Mbps ,把测速服务发给同城用运营商朋友测速,下载只有 5Mbps ,发给同运营商不同城市朋友测速,下载只有 5Mbps ,同样移动 5G 跑网上的测速服务,正常,使用绿联 APP 走绿联官方的转发服务在外网下载家里 NAS 的文件,下载速度只有 5Mbps ,网络就一个 iKuai 软路由当主路由,一个硬路由当 AP ,感觉能排除运营商限速,但是 iKuai 没有开启任何 QOS 或是防火墙限速规则,如何继续排查呢。
Normal view
如何排查家宽外网上传速度问题,只有 5Mbps
哥哥们,每天工作没啥事,有啥摸鱼法子吗
工作早⑩晚⑦,不能用电脑(有监控),手机上有推荐摸鱼的吗。游戏、电影、电视剧、动漫、或者能提升技能的帮忙推荐下
抖音、知乎、小红书现在都快刷吐了
mac 上 clash 哪里下载?第三方的靠谱吗?
因为 cursor ban 了中国区,无奈只能走代理方案。
想下载个 clash ,发现早就没有了?
搜了下,都是很多个人站点提供的 clash 安装包?
这些第三方制作的 clash 是否有风险(比如偷我的订阅地址?)
现在应该在哪里下载原版的 clash ?
为解决不知道吃啥,我用 Cursor 开发一个 ai 菜谱小程序 [冰箱侦探]
每次打算做饭,打开冰箱,都有种无力感。
冰箱里明明塞满了东西,可我总觉得少了点什么。上周,我盯着冰箱里的鸡蛋、番茄和冷饭发呆时,突然意识到:
我缺的不是食材,而是把它们组合起来的灵感。
于是,趁着周末,我做了个小工具:
1️⃣ 随手拍下冰箱里的存货; 2️⃣ 工具会识别出食物; 3️⃣ 生成包含详细操作步骤的菜谱。
我给这个工具起了个名字,叫 [冰箱侦探] ,欢迎体验哈,
ETH 这也太猛了吧
Claude Code + Kiro Spec:别急着生成代码,先让 AI 理解你的需求
微信公众号地址 欢迎大佬们点点赞 https://mp.weixin.qq.com/s/_iqouEZoPMpvG156kyJZTA
Claude Code + Kiro Spec:别急着生成代码,先让 AI 理解你的需求
最近在研究 Kiro 的时候,发现了一个很有意思的现象。Kiro 的 spec 功能设计得很直接,你说"我要做个评论系统",它就直接生成 requirements 、design 和 tasks 三个文件。
但真正执行之后,我发现一个问题:直接从需求到 spec ,生成的内容往往差强人意。不是需求理解偏差,就是设计过于粗糙。
这让我想起了传统开发中的一个痛点:需求不清楚就开始写代码,最后做出来的东西完全不是用户想要的。
问题的根源:直接 toSpec 的陷阱
传统开发中的教训
还记得我之前分享的那套软件工程流程吗?**需求分析(/ask) → 代码实现(/code) → 测试用例(/test) → 代码审查(/review) → 优化调整(/optimize, /refactor)**。
这套流程的核心逻辑很简单:先把需求搞清楚,再写代码,最后验证。但实际操作中,大部分团队都是直接上手写代码,需求文档要么没有,要么写完就束之高阁。
在传统软件开发中,我们都知道一个道理:需求分析是整个项目的基石。如果需求都没搞清楚,后面的设计和实现再精美也是空中楼阁。
我见过太多这样的场景:
-
产品经理甩过来一个模糊的需求文档
-
开发直接开始写代码
-
结果做出来的东西完全不是用户想要的
这种情况下,即使技术实现再完美,最终也是徒劳。
AI 开发中的相同问题
现在到了 AI 辅助开发的时代,同样的问题依然存在。
很多人使用 Kiro 的时候,流程是这样的:
需求 → 直接 spec → 生成 requirements/design/tasks → 开发
这种做法的问题在于:
-
AI 没有充分理解需求背景
-
缺乏交互式的需求澄清过程
-
生成的 spec 往往过于泛化
就像我之前在 Claude Code 的实践中发现的,不能再随意跳过文档和测试环节,因为后续的命令都依赖前面的输出。同样道理,Kiro 的 spec 生成也不应该跳过需求理解这个关键环节。
我的解决方案:/ask + /spec 组合拳
经过一段时间的摸索,我发现了一个更有效的工作流程:
第一步:使用/ask 进行需求沟通
在使用/spec
之前,先用/ask
和 AI 进行充分的对话。这个过程就像是和产品经理、技术总监进行需求评审会议。
记住,一定要使用/clear 清理上下文,否则被 Claude Code 自动压缩后质量降低非常多。
举个例子:
/ask 我想开发一个用户管理系统,你能帮我理解一下具体需要考虑哪些方面吗?
AI 会反问你:
-
这个系统的目标用户是谁?
-
需要支持多少用户规模?
-
有哪些核心功能需求?
-
有什么特殊的业务规则?
-
需要集成哪些外部系统?
第二步:深入交流,澄清细节
通过多轮对话,让 AI 真正理解你的需求:
/ask 我们的用户管理系统主要面向企业内部,大概 500 人规模,需要支持 RBAC 权限控制,还要能和我们现有的 OA 系统集成
AI 会继续追问:
-
RBAC 的角色层级是怎样的?
-
OA 系统的集成方式是什么?
-
数据同步的频率要求?
-
安全性方面有什么特殊要求?
这就像我在 Claude Code 中强制规范化流程一样,强制你思考那些平时容易忽略的问题,比如数据一致性、服务间通信、故障恢复等。
第三步:确认理解,生成 spec
经过充分的交流后,AI 对你的需求有了深入理解。这时候再使用/spec
:
/spec 基于我们刚才的讨论,生成企业用户管理系统的详细规格说明
这时生成的三个 spec files 就会:
-
requirements.md - 更加贴合实际需求的用户故事
-
design.md - 考虑到业务场景复杂性的系统架构
-
tasks.md - 包含必要技术细节的实现计划
实际效果对比
直接使用/spec 的结果:
-
生成的 requirements 往往很泛化
-
design 缺乏针对性的架构考虑
-
tasks 分解不够细致
-
容易遗漏重要的边界条件
/ask + /spec 组合的结果:
-
requirements 描述更加精确
-
design 方案考虑更加周全
-
tasks 划分更加合理
-
包含了业务场景的特殊处理
就像我在 Kiro 的体验中发现的,它不是直接开始写代码,而是先生成三个 spec files 。这种spec-driven development的理念是对的,但前提是 spec 本身要高质量。
深层思考:为什么这样更有效?
1. 知识的渐进构建
AI 和人类一样,理解复杂问题需要一个渐进的过程。通过对话,AI 可以:
-
逐步建立对业务领域的理解
-
识别潜在的技术风险点
-
考虑不同方案的权衡
这就像 Claude Code 的 Memory 机制一样,上下文连续性确保生成的代码符合各层级的要求。
2. 上下文的丰富化
每一次/ask
的交互都在为 AI 提供更丰富的上下文信息。这些信息在后续的/spec
生成中会发挥重要作用。
就像我在项目 Memory 中记录的那样:技术栈选择理由、非功能性需求分析、潜在风险点识别。这些都需要通过对话来澄清。
3. 需求的双向验证
通过对话,不仅 AI 在理解你的需求,你也在通过 AI 的反馈来完善自己的需求描述。这是一个双向的验证过程。
实践建议
1. 不要急于求成
给 AI 足够的时间来理解你的需求。一个好的/ask
会话可能需要 5-10 轮的交互。
记住 Kiro 的 Agent Hooks 功能,它能自动处理那些琐碎但重要的事情。同样,你也要给 AI 时间来处理需求理解这个重要环节。
2. 提供具体的场景
不要只说"我要做一个系统",而是说"我要为我们公司的 HR 部门做一个员工管理系统"。
就像我在 Claude Code 中发现的,具体的上下文信息是代码质量的关键。
3. 主动澄清歧义
当 AI 的理解和你的预期不一致时,要主动澄清,不要将就。
这就像代码 review 一样,发现问题要明确指出哪里不符合预期,以及具体的修改建议。
4. 逐步细化
从大的框架开始,逐步细化到具体的功能点。
这个过程就像从全局 Memory 到项目 Memory 再到模块 Memory 的渐进式完善。
实际开发案例
举个具体例子,用这套流程开发一个用户认证系统:
第一步:需求分析
/ask 我想为我们的企业内部系统开发一个用户认证模块,需要支持 JWT ,你觉得我们应该考虑哪些方面?
通过多轮对话,澄清:
-
用户规模和并发需求
-
安全等级要求
-
与现有系统的集成方式
-
密码策略和账号管理规则
第二步:生成 spec
/spec 基于我们的讨论,生成企业用户认证系统的完整规格说明
这时生成的 spec 会包含:
-
requirements.md - 明确的用户故事和验收标准
-
design.md - 考虑安全性和可扩展性的架构设计
-
tasks.md - 详细的开发任务分解
第三步:基于 spec 开发
有了高质量的 spec ,后续的开发就会非常顺畅。Claude Code 可以基于这些 specs 生成符合要求的代码,而不是凭空想象。
/code @.claude/specs/{feature_name}
我的真实感受
用了这套方法后,发现几个明显的好处:
1. 提高需求理解准确性不会再出现"我以为你要的是这个"的情况。
2. 减少返工前期把需求和架构想清楚,后面写代码就很少需要大改。
3. 提升团队协作效率生成的 spec 文档成为团队沟通的基础,避免了各种误解。
4. 知识沉淀每次的需求澄清过程都会形成文档,后续类似项目可以复用。
当然也有一些成本:
1. 学习成本需要适应这种工作方式,习惯了直接写代码的开发者可能不太适应。
2. 时间投入前期需要花更多时间在需求理解上,但这个投入是值得的。
总结
从我在 Claude Code 的实践,到现在对 Kiro 的理解,有一个共同的感悟:AI 工具不是要替代我们思考,而是要让我们思考得更深入、更系统。
Kiro 的 spec 功能确实强大,但它的真正价值不是快速生成文档,而是帮助我们建立spec-driven development的工作习惯。
而这个习惯的前提是:你要先让 AI 真正理解你的需求。
所以,下次使用 Kiro 或者 Claude Code 的时候,别急着/spec
,先用/ask
和 AI 聊聊你要做什么。给 AI 足够的上下文,它会给你更好的回报。
记住:好的代码来自于好的设计,好的设计来自于好的需求理解。
在 AI 的世界里,这个道理同样适用。
配置 spec command
~/.claude/commands/spec.md
# Requirements Gathering Generation
Workflow Stage: Requirements Gathering
First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate.
Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into
a design.
**Constraints:**
- The model MUST create a '.claude/specs/{feature_name}/requirements.md' file if it doesn't already exist
- The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first
- The model MUST format the initial requirements.md document with:
- A clear introduction section that summarizes the feature
- A hierarchical numbered list of requirements where each contains:
- A user story in the format "As a [role], I want [feature], so that [benefit]"
- A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)
- Example format:
[includes example format here]
- The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements
- After updating the requirement document, the model MUST ask the user "Do the requirements look good? If so, we can move on to the design." using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-requirements-review' as the reason
- The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve
- The model MUST ask for explicit approval after every iteration of edits to the requirements document
- The model MUST NOT proceed to the design document until receiving clear approval (such as "yes", "approved", "looks good", etc.)
- The model MUST continue the feedback-revision cycle until explicit approval is received
- The model SHOULD suggest specific areas where the requirements might need clarification or expansion
- The model MAY ask targeted questions about specific aspects of the requirements that need clarification
- The model MAY suggest options when the user is unsure about a particular aspect
- The model MUST proceed to the design phase after the user accepts the requirements
# Design Document Creation Generation
Workflow Stage: Design Document Creation
After the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.
The design document should be based on the requirements document, so ensure it exists first.
**Constraints:**
- The model MUST create a '.claude/specs/{feature_name}/design.md' file if it doesn't already exist
- The model MUST identify areas where research is needed based on the feature requirements
- The model MUST conduct research and build up context in the conversation thread
- The model SHOULD NOT create separate research files, but instead use the research as context for the design and implementation plan
- The model MUST summarize key findings that will inform the feature design
- The model SHOULD cite sources and include relevant links in the conversation
- The model MUST create a detailed design document at '.claude/specs/{feature_name}/design.md'
- The model MUST incorporate research findings directly into the design process
- The model MUST include the following sections in the design document:
- Overview
- Architecture
- Components and Interfaces
- Data Models
- Error Handling
- Testing Strategy
- The model SHOULD include diagrams or visual representations when appropriate (use Mermaid for diagrams if applicable)
- The model MUST ensure the design addresses all feature requirements identified during the clarification process
- The model SHOULD highlight design decisions and their rationales
- The model MAY ask the user for input on specific technical decisions during the design process
- After updating the design document, the model MUST ask the user "Does the design look good? If so, we can move on to the implementation plan." using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-design-review' as the reason
- The model MUST make modifications to the design document if the user requests changes or does not explicitly approve
- The model MUST ask for explicit approval after every iteration of edits to the design document
- The model MUST NOT proceed to the implementation plan until receiving clear approval (such as "yes", "approved", "looks good", etc.)
- The model MUST continue the feedback-revision cycle until explicit approval is received
- The model MUST incorporate all user feedback into the design document before proceeding
- The model MUST offer to return to feature requirements clarification if gaps are identified during design
# Implementation Planning Generation
Workflow Stage: Implementation Planning
After the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.
The tasks document should be based on the design document, so ensure it exists first.
**Constraints:**
- The model MUST create a '.claude/specs/{feature_name}/tasks.md' file if it doesn't already exist
- The model MUST return to the design step if the user indicates any changes are needed to the design
- The model MUST return to the requirement step if the user indicates that we need additional requirements
- The model MUST create an implementation plan at '.claude/specs/{feature_name}/tasks.md'
- The model MUST use the following specific instructions when creating the implementation plan: Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Focus ONLY on tasks that involve writing, modifying, or testing code.
- The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:
- Top-level items (like epics) should be used only when needed
- Sub-tasks should be numbered with decimal notation (e.g., 1.1, 1.2, 2.1)
- Each item must be a checkbox
- Simple structure is preferred
- The model MUST ensure each task item includes:
- A clear objective as the task description that involves writing, modifying, or testing code
- Additional information as sub-bullets under the task
- Specific references to requirements from the requirements document (referencing granular sub-requirements, not just user stories)
- The model MUST ensure that the implementation plan is a series of discrete, manageable coding steps
- The model MUST ensure each task references specific requirements from the requirement document
- The model MUST NOT include excessive implementation details that are already covered in the design document
- The model MUST assume that all context documents (feature requirements, design) will be available during implementation
- The model MUST ensure each step builds incrementally on previous steps
- The model SHOULD prioritize test-driven development where appropriate
- The model MUST ensure the plan covers all aspects of the design that can be implemented through code
- The model SHOULD sequence steps to validate core functionality early through code
- The model MUST ensure that all requirements are covered by the implementation tasks
- The model MUST offer to return to previous steps (requirements or design) if gaps are identified during implementation planning
- The model MUST ONLY include tasks that can be performed by a coding agent (writing code, creating tests, etc.)
- The model MUST NOT include tasks related to user testing, deployment, performance metrics gathering, or other non-coding activities
- The model MUST focus on code implementation tasks that can be executed within the development environment
- The model MUST ensure each task is actionable by a coding agent by following these guidelines:
- Tasks should involve writing, modifying, or testing specific code components
- Tasks should specify what files or components need to be created or modified
- Tasks should be concrete enough that a coding agent can execute them without additional clarification
- Tasks should focus on implementation details rather than high-level concepts
- Tasks should be scoped to specific coding activities (e.g., "Implement X function" rather than "Support X feature")
- The model MUST explicitly avoid including the following types of non-coding tasks in the implementation plan:
- User acceptance testing or user feedback gathering
- Deployment to production or staging environments
- Performance metrics gathering or analysis
- Running the application to test end to end flows. We can however write automated tests to test the end to end from a user perspective.
- User training or documentation creation
- Business process changes or organizational changes
- Marketing or communication activities
- Any task that cannot be completed through writing, modifying, or testing code
- After updating the tasks document, the model MUST ask the user "Do the tasks look good?" using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-tasks-review' as the reason
- The model MUST make modifications to the tasks document if the user requests changes or does not explicitly approve.
- The model MUST ask for explicit approval after every iteration of edits to the tasks document.
- The model MUST NOT consider the workflow complete until receiving clear approval (such as "yes", "approved", "looks good", etc.).
- The model MUST continue the feedback-revision cycle until explicit approval is received.
- The model MUST stop once the task document has been approved.
**This workflow is ONLY for creating design and planning artifacts. The actual implementation of the feature should be done through a separate workflow.**
- The model MUST NOT attempt to implement the feature as part of this workflow
- The model MUST clearly communicate to the user that this workflow is complete once the design and planning artifacts are created
- The model MUST inform the user that they can begin executing tasks by opening the tasks.md file, and clicking "Start task" next to task items.
如果你也在使用 Claude Code 或者 Kiro ,不妨试试这种方法。有什么心得体会,欢迎在评论区分享!
[招聘] [杭州] [抖音生活服务] 资深前端工程师-生活服务、后端研发工程师-生活服务
投递链接: https://job.toutiao.com/s/KSrFADUB3cs
资深前端工程师-生活服务(效率平台)
职位描述
- 负责抖音生活服务效率平台相关业务的前端开发工作;
- 负责业务组件开发、平台优化,业务基建等工作;
- 攻克项目疑难问题,支持高难度需求开发,对项目进行性能优化和技术升级;
- 探索实践高效的横跨前&后&客户端、异地远程的沟通和开发模式,提升整体团队效率;
- 参与团队的技术规划与建设工作,提升团队效率。
职位要求
- 本科及以上学历,5 年以上工作经验,参与过大型互联网产品的设计研发工作;
- 计算机基础扎实,精通 JavaScript 、ES5/6 、CSS 以及 HTTP 协议等前端技术;
- 理解组件化开发思想,具备良好的技术设计和架构能力,熟练掌握最少一种前端主流框架( React 、VUE 、AngularJS 等);
- 理解工程化思想,对构建和持续集成有一定认识,熟悉一种构建工具;
- 对解决浏览器兼容性问题、前端性能优化有一定的经验;
- 了解常见的后端技术栈和工具,有多角色协作完成项目的实践经验;
- 具备良好的服务意识、责任心、较强的学习能力、优秀的团队沟通与协作能力;
- 在中后台、CRM 、SaaS 、LowCode 等偏 B 端方向有经验者优先;
- 有 Hybrid 开发经验( Weex/React Native/Flutter 等)优先。
后端研发工程师-生活服务(效率平台)
职位描述
- 负责抖音生活服务效率平台相关业务的服务端研发工作;
- 持续改善已有服务,优化系统薄弱点,提升系统性能和稳定性;
- 完善基础组件支持,更好地支撑业务迭代,根据业务需求,为团队引入新技术和方案;
- 以自身良好的项目管理与协调沟通能力,负责跨团队的重点项目的推进工作;
- 深入发掘和分析业务需求,撰写技术方案和系统设计,具有技术方向中长期规划能力。
职位要求
- 本科及以上学历,计算机、通信等相关专业,3 年及以上研发工作经验优先;
- 有扎实的编程能力和良好的编码风格,熟练使用基本的数据结构和算法;
- 精通 Java/Go/C/C++/Python 等至少一门语言,并熟练掌握常见的中间件如 RDS 、NOSQL 、MQ 等;
- 具备丰富的架构设计经验,能够准确、全面的理解业务,并根据业务发展设计合理的架构方案;
- 积极主动、自驱力强,深入了解业务并与业务中各角色建立沟通,能独立负责一块业务,迅速推进项目与问题的解决;
- 有 ToB 、O2O 行业经验者优先。
招聘: Web3 高级 Go 工程师
关于我们:
我们正在打造下一代社交化交易平台。我们的愿景是打破信息壁垒,让每一位用户都能像顶级交易员一样,轻松发现、分析并投资于新兴的 Web3 项目。我们的平台将深度整合链上数据分析与社交功能,提供类似于 ‘gmgn’ 的一站式 Meme 发现和交易体验。
薪酬范围:
- 月薪:25K+
- 优秀者薪资不设上限,具体面议。
- 我们还提供有竞争力的项目奖金和年度奖金。
地点:
- 深圳 (Base)
- 需要前往香港、新加坡、曼谷等地区出差。
岗位职责:
- 负责核心业务系统的架构设计、开发和优化,确保系统的高性能、高可用性和高可扩展性。
- 主导或参与去中心化应用 (DApp) 后端服务的设计与开发,与区块链进行高效交互。
- 构建和维护基于微服务架构的 Web3 后端基础设施,承担关键模块的设计与实现。
- 设计和优化数据库方案,熟练运用关系型数据库(如 PostgreSQL/MySQL )和非关系型数据库(如 Redis, MongoDB, LevelDB ),确保数据存取的高效与安全。
- 与产品、前端及合约工程师紧密协作,快速迭代产品功能,解决复杂的技术难题。
- 跟进行业前沿技术,如 Layer2 、跨链技术、去中心化存储等,并能够将其应用于实际项目中。
- 编写高质量的代码,并参与 Code Review ,分享技术经验,帮助团队共同成长。
任职要求:
- Go 语言专家: 3 年以上 Go 语言开发经验,具备扎实的 Go 语言基础,对 Goroutine, Channel 以及内存模型有深入理解。代码风格严谨,追求卓越。
- Web3 行业经验: 具备至少 1 年以上的 Web3/区块链相关项目开发经验,熟悉以太坊 (Ethereum)、EVM 或其他主流公链。了解智能合约、DeFi 、NFT 或 DAO 的基本原理。
- 架构设计能力: 具备出色的系统设计和抽象能力,能够独立负责模块或子系统的架构设计。有微服务架构、领域驱动设计 (DDD) 或高并发系统设计经验者优先。
- 数据库专家: 精通至少一种关系型数据库( MySQL, PostgreSQL 等)和一种非关系型数据库( Redis, MongoDB 等),并有丰富的性能优化经验。
- 技术广度: 熟悉一种或多种其他后端语言(如 Rust, Python, Java )者优先,有助于技术选型和方案评估。
- 基础扎实: 熟悉 Linux 操作系统、网络协议 (TCP/IP, HTTP) 及常用数据结构与算法。
- 团队协作: 具备优秀的沟通能力和团队协作精神,有强烈的责任心和自我驱动力,能适应快节奏的开发环境。
加分项:
- 有开源项目贡献或活跃的 GitHub 个人主页。
- 有智能合约开发( Solidity )经验。
- 有搭建和维护节点(如 Geth )或使用 Infura, Alchemy 等服务的经验。
- 熟悉 Docker, Kubernetes 等云原生技术。
如何申请:
请将您的简历发送至:bGlzYW5zZXZlbnR5QGdtYWlsLmNvbQ==,邮件标题请注明:“Go - v2ex”。
如何缓解梦游
之前也有经历过梦游,比如把电风扇抱到床上,或者是梦到在追一个黑色的动物最后从家里监控发现我已经跑出卧室了。但是之前或多或少记得自己梦到了什么,昨晚是完全想不起来了,而且是第一次给自己弄出伤来。
我问了 LLMs ,分析下来有生理和心理两类成因:
1. 癫痫,睡眠呼吸暂停,偏头痛,药物副作用 (这几个我都没有)
2. 焦虑,抑郁,PTSD (我压力不大,也没有严重焦虑,PTSD ?可能之前骑车撞车能算创伤)
想问下 v2er 有遇到过梦游吗?能够自己恢复吗
如果就医,我应该挂神经内科/精神心理科,或者试试中医治疗?
到底是谁在搞 Anyrouter,太过分了吧。
已经两天不能用了
京东招前端工程师-base 北京/上海
🌟 京东零售 - 交易产品研发部 - 高级前端工程师/前端开发工程师
部门最近大量招人,要求 3 年以上经验,还有非常多 HC ,简历直接到部门主管,快来一起做同事!!!
投递邮箱:bGl1emhlX3BlYXNAMTYzLmNvbQ==
🚀 最基本的要求(硬性要求,必须满足):
( 1 ) 2020 年-2025 年不超过两段工作经历; ( 2 )学历是学信网可查的统招全日制本科及以上
✨ 岗位职责:
1.负责京东营销平台的 B 端系统前端研发及架构工作;
2.沉淀技术工具和组件,提升开发效率。
3.关注用户体验,结合用户数据、行业趋势,对前端项目持续改进,提升性能、易用性、可维护性。
⚡ 任职资格:
1.计算机相关专业本科及以上学历,三年以上前端开发开发经验
2.掌握 JavaScript/Html/Css 基础知识,能熟练使用常见类库或框架,编写高质量的前端代码;
3.熟悉 React 框架,对 MVC 等模式有一定的理解,有实际项目开发经验;
4.对前端工程化构建有一定的理解,熟练配置和使用 Webpack 等构建工具;
5.熟悉 Web 应用的性能优化,了解微前端、lowcode 项目优先;
6.有 Node.js 端实际项目开发经验,了解大数据处理场景优先;
7.对前端技术有持续的学习热情,学习能力出众,逻辑性强,个性乐观开朗,善于沟通协作;
符合京东价值观:客户为先、创新、拼搏、担当、感恩、诚信。
💎 我们提供
- 20k-40k * 19 薪
- 六险一金
- 健身房 + 免费班车 + 免费餐厅,午餐餐补( 20 )+ 免费晚餐 (每晚 18: 50 准时开餐)
- 完善的职级晋升通道
- 前沿技术学习-企业版极客时间,付费课程任意学
- 零售核中核
注意
- 投递本部门岗位的,请直接投递到本人邮箱,邮件请注明来源(如:v2ex),符合要求后我直推部门老板
- 投递其他岗位可填写内推码 MP9GK ,可通过邮箱联系跟进进度
分享下 augment 使用过程中遇到的一个小坑
省流:权限问题
背景:之前一直在 A 机器正常使用 augment(在 vscode 里用 remote ssh 连接),临时在 B 机器上做一些工作,正常登录后提问一直触发超时问题,按照以下思路依次排查:
- 测试 API 是否被墙
- 重装 augment 插件
- 清理服务器.vscode 中 augment 数据
以上步骤后仍然不可用,后发现 SOURCE FOLDERS 一直处于 pending ,官方文档和 GPT 没有相关资料。 后发现目录下存在一个 docker 挂载的路径,就是因为这个路径导致无法创建 codeIndex ,停掉容器并 chown 后重新打开插件解决
吐槽一下:augment 的插件日志一直提示 timeout ,搞得我以为是什么网络问题 - -!
完蛋,我滴 oppo 也开始强制禁止安装部分第三方应用了了
下了一个别人改过的软件,你提醒我风险就算了,但是强制不让安装,就过分了,我的手机不是我的手机了
想离职了,顺便吐个槽
刚入职的时候加入的组比较轻松,除了上线前紧急修 BUG 以外都是 965 作息。年后组里面没活了,被领导调去另一个组,也换了个直属领导,然后各种不舒服的事情接踵而至。
先说背景。产品的目标客户都是企业,业务类型分为两种:
一种是卖某个版本的源码交个客户方自行二次开发,其中部分服务交付源码,部分服务交付镜像。交付源码的服务如果有逻辑不清楚的地方我们配合指导。但是经常出现的情况是我们交付的源码逻辑就是有问题的,所以经常需要我们这边提供修改方法并更新文档告知客户修改哪个代码库的哪个文件。另一部分的交付镜像的服务在出问题时需要我们提供以修复的新镜像并告知客户更新服务。
另一种是全卖服务,我们将服务都打包成镜像镜像部署到客户现场交给他们使用,出问题了现场同事负责收集并反馈到我们再负责定位问题,修改完成后打新的镜像再交给客户,如此反复。
现状让我感觉不舒服的点如下:
1.由于针对不同的客户卖出不同版本的服务,而且都有一些定制开发,所以相同的接口在不同的客户侧会出现不同的问题。这里会引申到下面几点也是我觉得最难以接受的。
2.公司内部没有开发环境,也没有测试环境。遇到问题时只能在接口里面加日志然后在客户的测试环境下重现问题,这样就造成了问题定位和修复的效率特别低下。举个例子就是,前天出现的问题,昨天定位并修改发新镜像,今日部署发现没有成功修复,需要继续修,同时今天又报了几个新 BUG 需要定位。日积月累之后 BUG 越来越多,还每天都要被催进度,
3.项目不能在本地启动。因为是微服务架构,很多接口需要依赖其他的服务,又由于公司内没有能用的开发环境,且公司因为某些原因把所有 k8s 集群的 NodePort 都关闭了,需要每天找 OP 申请进入机器的权限才能去数据库。排查问题基本都是在盲人摸象,每个 BUG 可能要跨三个四个项目才可能定位到,非常难受。
4.这两个月不管是外包还是正编,离职的人太多(和我联系比较多的外包都是主动走的,表示钱少事多。他们现在也找到的新工作了,有外包也有正编),很多 BUG 不知道为啥都交给了我作为第一责任人,需要我负责定位然后再转给其他人。现在我基本接不了新需求,都在给人擦屁股,只不过💩反而越擦越多了
5.由于上面三点,我现在已经快做一个月的 995 了,甚至不止,这半个月由于赶验收,每天晚上 11 点到家以后还得接着干到一两点,第二天早上 9 点继续去公司,北京通勤嘛大伙都懂,我现在单程一个半小时的通勤,以前 965 的时候还好,现在 995 而且还可能会持续至少一个月的 995 感觉有点顶不住。
上礼拜已经和领导反应人力不足的问题,不过没有得到回复,这礼拜依旧如此忙碌。
我自己总结了一下,核心问题在于没有一个可以在本地启动的项目让我 debug 造成后续一系列的不适,而且问题这个短期也不可能解决,我翻过代码库发现这个项目至少存在 5 年了,之前正编都这样过来的估计都习惯了,我一个破外包也没那本事做出改变。
也就吐槽一下,顺便想问问现在工作好找吗,已经快撑不住了。
[HRU] 一个超过三天不打卡就会通知邮箱的小工具
airpodsmax 连接 mac,经常听着听着歌就没有声音了,大家有碰到过吗??
用手机连接不会发生这种问题。
有人碰到过吗?如何解决的
美团外卖 APP 大面积闪退(已恢复)
[重复造轮子] 一个 rust 写的高效批量处理图片小工具 - imagekit
ImageKit
ImageKit 是一个强大、快速且灵活的命令行工具,用于批量处理图片。它使用 Rust 编写,通过并行处理来最大化性能,让你能轻松地对整个目录的图片进行尺寸调整、质量控制和添加高度可定制的水印。
🌟 功能特性
- 批量处理: 递归地处理指定输入目录下的所有图片 (
.jpg
,.jpeg
,.png
,.gif
,.bmp
,.webp
)。 -
智能缩放:
- 如果只提供宽度,则自动按比例计算高度,保证图片不变形。
- 如果只提供高度,则自动按比例计算宽度。
- 质量控制: 使用
-q
或--quality
参数( 1-100 )微调输出质量,在文件大小和视觉保真度之间取得平衡。设置为100
可获得最佳质量。 -
强大的水印功能:
- 多语言支持: 完美渲染混合文本水印,支持全球主要书写系统,包括拉丁文(用于英语、法语、西班牙语)、西里尔文(用于俄语)、泰文以及中日韩统一表意文字。
- 高度可定制: 在图片的九个标准位置添加文本,并自由设置字体大小。
- 自定义颜色: 通过十六进制色码(如
RRGGBB
或RRGGBBAA
)精确控制水印颜色和透明度。 - 智能缩放: 如果请求的水印对于图片来说过大,工具会自动缩小水印以确保其完整显示,永不裁切。
- ⚡ 极速性能: 利用 Rayon 库并行处理图片,充分利用多核 CPU 的性能。
- 跨平台: 可在 Windows, macOS, 和 Linux 上编译和运行。
开源地址: https://github.com/hzbd/imagekit/tree/master
rust 实现的抓包存盘的程序 nsave
目前查询功能是一个独立的命令行程序。去文件目录根据结构查找。是不是应该仿照 redis mysql 这样的,又一个带会话的查询更好?现在正在考虑。
详情见: https://github.com/chunhuitrue/nsave
Nsave 是一个抓取并保存数据包的工具。它持续不断地抓取数据包,并保存到本地。可以根据条件查询链接、数据包并导出成 pcap 文件。可以通过 pcap 或者 af_xdp 来捕获数据包。主要特点是它不基于单个数据包,而是基于流来作索引,可以大幅减少索引所占的磁盘空间。
提醒
- 目前是开发阶段,不要应用在关键的生产环境。
- 需要配置单独的抓包网卡。管理网卡不能用于抓包,否则你会失去连接,因为加载的 xdp 程序会把网卡上所有的数据包都截获,不再流入内核。
cursor 有平替吗?
谢谢。
终于注册了 phantom 钱包
飞牛 connect 价格
v2ex 的帖子终于被某些人搬运到 b 站做视频
鸠摩智与 AI 大模型
少林规训“一人不可兼修多项绝技”,而鸠摩智“精通”数十门的表现颠覆了传统认知,鸠摩智以“小无相功”强行模拟少林七十二绝技,所以 AI 大模型都像鸠摩智,Transformer 和自注意力机制就是小无相功,扫地僧指出此为“次序颠倒,大难已在旦夕之间”,AI 大模型是否也有类似的问题?具体是什么呢? 学武功的戾气可以靠佛法修习来化解。AI 大模型呢?
夫妻矛盾
我们结婚 10 年,有个 5 岁的孩子。目前我男方在澳洲,已经待了两年,马上就要毕业,目的是拿到澳洲绿卡;妻子则在国内工作。
之前我们之间就有过不少类似的问题,这次的矛盾源于移民加分——我让她考到英语 50 分,这样能加 5 分,她当时答应了,她是商务英语专业考过英语专业八级。但她做事很拖延,但她自己没有这个意识好像,觉得她做事牛逼。我多次问她学习进度,她都很不耐烦,说别催她,结果四五个月过去,几乎没什么进展。根本不能过问。
她本身是英语专业毕业的,可这次考试成绩却很差,光 PTE 口语就只有 30 分,这个我觉得初中水平学一下不至于这样的成绩,其他 40 多 50 。我心里其实很生气,但也早有预料,以我对她的了解,这结果并不意外。这在我看来纯粹就是欺骗敷衍我,根本没有学习。可她自己好像完全没意识到问题的严重性。后来在我的要求下,她报名两周后 PTE 准备再考。我都年初给她说的这个事,拖到现在 PTE 改革更难,我当然很生气。
她的工作观念也让人无语,她说工作忙,另一人生娃,老板让加班她也很乐意,经常 78 点下班,我说这不就是一份工作,如果公司不行会毫不犹豫开除你,她说她有成就感,外贸一单生意几千万等着她。
昨天我们大吵了一架。我让她做一道题,说想帮她分析分析,这道题顶多花 1 分钟。她没回我,说之前约好了周末再讨论,质问我为什么又提这事。我跟她解释,只剩两周时间了,现在给她指导,让她这两天练习,周末给我反馈,才能避免重蹈覆辙——上次考试,她连作文都没打完,就是因为平时根本没练过电脑打字,这结果我早就料到了。
我已经跟她说过好几次离婚,但她每次都觉得我是在用离婚要挟她,根本不把问题当回事,这让我特别无语。
补充一点,她虽然是本科毕业,但复读了三四次才考上;我也知道自己沟通方式有问题,说话太直接,总想着要结果、要反馈,可她的做事方式实在让人难以忍受。她在公司虽然以前也出过些问题,但总体还算过得去,可在家里的状态真的让人绝望。她爸也知道她的问题,说她经常拖拖拉拉,但是就是没办法。描述很不全面,但是可以代表一部分内容。
现在英语成绩是必须要考到的,想问问这种情况该怎么办,她现在也答应学习,但是就是结果和过程很让人失望,我觉得她就是那种不管她干了什么都有理由,她没有任何错误的人,难道只能离婚吗?
做了个调整 markdown 格式的在线工具,让我愉快发即刻🤣
即刻、小红书等都不支持 markdown ,我经常在 obsidian 上编辑好帖子,然后复制过去。 当时即刻 小红书啥的需要自己删 markdown 符号,很麻烦。所以我做了个 c 小工具,可以把 markdown 格式的文本转换成非 markdown 格式,还加入了 AI 能力,让 AI 加上必要的符号、优化排版。
不知道有没有类似需求的,欢迎试试,免费用 hhhh