Reading view

There are new articles available, click to refresh the page.

What happens in the log when an app crashes as it starts up?

In yesterday’s guide to dealing with apps that crash immediately you open them, I carefully avoided mentioning what you might find in the log. This article puts that right.

The list of common causes I gave is:

  • macOS intentionally crashed the app because of an error in code signing, or another serious security failure;
  • the app failed because it was in translocation;
  • the app couldn’t open a damaged or incompatible document;
  • the app had a problem with its Preferences.

Investigating these in the log is among the simplest tasks for those learning to access it, providing the app crashes reliably. Show the seconds value in the menu bar clock, and open the Applications folder containing the app. Select it as the seconds reach about 45, to allow time for its icon to be displayed, then double-click the app to run it as the seconds reach 00, but not a moment earlier. Don’t touch the mouse/trackpad or keyboard for at least 5 seconds, by which time the crash should have occurred and the notification or crash log should have been displayed.

Then open LogUI (or a substitute), and set it to extract and display all the entries for 5 seconds from 00 seconds. If you open a new window in LogUI the start time will be preset to the time you opened the app, all ready to get the log extract.

The double-click is easy to spot in the log, as it’s marked by four almost identical Activity entries with a yellow 🥎 softball emoji, each reading something like
AppKit Finder sendAction:
short entries that are quick to locate. Entries following the fourth of those then report what happened next.

Code signing errors

These are normally easy to recognise, as they start with a call to verify the signature,
00.940943 Finder sendAction:
00.963228 syspolicyd SecTrustEvaluateIfNecessary
00.963982 trustd SecKeyVerifySignature

that’s followed by an error that’s repeated many times,
00.981296 lsd com.apple.securityd MacOS error: -67030

Follow those down a bit further and you’ll see this reported in other subsystems
01.013084 com.apple.launchservices Error -67030 validating the signing information for [private], error=Error Domain=NSOSStatusErrorDomain Code=-67030 "(null)" UserInfo={SecCSArchitecture=arm64}

Normally, this will be checked again by AMFI (Apple Mobile File Integrity)
01.030162 amfid Entering OSX path for /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd
01.031629 amfid SecKeyVerifySignature
01.036291 amfid com.apple.securityd MacOS error: -67030
01.048491 error amfid com.apple.MobileFileIntegrity.framework Code failed basic validity check (error: -67030): Error Domain=NSOSStatusErrorDomain Code=-67030 UserInfo={SecCSArchitecture=[private]}
01.048857 amfid /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd not valid: Error Domain=AppleMobileFileIntegrityError Code=-420 "The signature on the file is invalid" UserInfo={NSURL=file:///Users/hoakley/Documents/
000aa/DelightEd.app/Contents/MacOS/DelightEd, NSLocalizedDescription=The signature on the file is invalid}

That’s confirmed and actioned by the kernel
01.048950 kernel AMFI: code signature validation failed.
01.052968 amfid com.apple.MobileFileIntegrity [private]: Broken signature with Team ID fatal.
01.053043 kernel AMFI: When validating /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: The code contains a Team ID, but validating its signature failed. Please check your system log.
01.053052 kernel mac_vnode_check_signature: /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: code signature validation failed fatally: When validating /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd: The code contains a Team ID, but validating its signature failed. Please check your system log.
01.053059 kernel validation of code signature failed through MACF policy: 1
01.053061 kernel check_signature[pid: 2718]: error = 1
01.053066 kernel proc 2718: load code signature error 4 for file "DelightEd"
01.053461 kernel AMFI: hook..execve() killing xpcproxy (pid 2718): Attempt to execute completely unsigned code (must be at least ad-hoc signed).
01.053624 kernel ASP: Sleep interrupted: ref 29, signal 0x100, pid: 2718

with the conclusion
01.053627 kernel ASP: Security policy would not allow process: 2718, /Users/hoakley/Documents/000aa/DelightEd.app/Contents/MacOS/DelightEd

You’re not likely to miss those.

Common error codes from signature validation include:

  • -2147409652 CSSMERR_TP_CERT_REVOKED, the certificate has been revoked
  • -67007 resource envelope is obsolete (version 1 signature)
  • -67008 unsealed contents present in the root directory of an embedded framework
  • -67013 resource envelope is obsolete (custom omit rules)
  • -67021 nested code is modified or invalid
  • -67023 invalid resource directory (directory or signature have been modified)
  • -67030 invalid Info.plist (plist or signature have been modified)
  • -67054 a sealed resource is missing or invalid
  • -67056 code has no resources but signature indicates they must be present
  • -67061 invalid signature (code or signature have been modified)
  • -67062 code object is not signed at all, which is by far the most common.

In this case, I had changed a single character in the app’s Info.plist, which broke its CDHashes, and resulted in the correct error code of -67030.

App translocation

In this case, you’re looking for two related pieces of evidence, that a process mentions the act of translocation, and that the app is run from a translocation location. Again, these normally aren’t hard to find.

Shortly after the double-click,
00.968186 Finder sendAction:
you should see mention of the creation of the translocation directory
01.040587 lsd com.apple.securityd SecTranslocateCreateSecureDirectoryForURL: created /private/var/folders/x4/
x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app

A little further down the log you’ll see the app being referenced in that long path
01.069877 amfid Entering OSX path for /private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/
B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app/Contents/MacOS/DelightEd
01.090927 com.apple.runningboard _executablePath = /private/var/folders/x4/x00kny5x0_5dsnmmxhtw6hc80000gn/T/AppTranslocation/
B9651238-6B8C-4750-BFAC-E0D1A327768C/d/DelightEd.app/Contents/MacOS/DelightEd

and so on.

If you’re struggling to find those, select the Messages item at the right end of the toolbar in LogUI, type the app name into the search box there and press Return, to filter entries.

Failed to open document

Of the four common causes of early app crashes, these are hardest to find evidence in the log. This is because the only process likely to know what went wrong is the app itself, and few third-party apps write anything useful to the log. You might find a useful entry or two by setting that menu at the right end of LogUI’s toolbar to Processes, entering the app name into the search box, and pressing Return. However, in many cases there will be little or no useful information.

Preference file problems

My previous article referred only to standard preferences that are handled by cfprefsd. Some apps run their own preferences using their own code, and neither cfprefsd nor the defaults command covers them. If they have a problem when accessing those custom files, it’s most unlikely to be recorded in the log.

In other apps, you should look for evidence that the crash happened shortly after the cfprefsd service is connected to the app, to support the standard features.

Starting once again with the double-click
01.579559 Finder sendAction:
it may take some time for the opening stages to complete. You should then see the XPC connection between the app and cfprefsd being set up for both root and the user
01.638428 DelightEd com.apple.xpc [0x102cf6980] activating connection: mach=true listener=false peer=false name=com.apple.cfprefsd.daemon
01.638504 DelightEd com.apple.xpc [0x102cf7960] activating connection: mach=true listener=false peer=false name=com.apple.cfprefsd.agent
01.638563 cfprefsd com.apple.xpc [0xa252bdb00] activating connection: mach=false listener=false peer=true name=com.apple.cfprefsd.daemon.peer[2910].0xa252bdb00
01.638659 cfprefsd com.apple.xpc [0x86f2d3600] activating connection: mach=false listener=false peer=true name=com.apple.cfprefsd.agent.peer[2910].0x86f2d3600

The app will normally crash during or shortly after the loading of preferences, marked by entries like
01.641152 DelightEd Loading Preferences From User CFPrefsD
01.706158 DelightEd Loading Preferences From System CFPrefsD

These too can be found more easily by setting the menu at the right end of LogUI’s toolbar to Processes, entering the app name into the search box, and pressing Return.

Happy hunting!

How to fix an app that crashes as it starts up

One of the most common and frustrating problems with apps is when they crash as soon as you try to open them. Before that app has even had a chance to display its menu bar or splash screen, it has vanished, leaving you without a clue as to why. How could its developer release an app that can’t even run? Where do you look for clues as to what happened when the app was only there for an instant? Fortunately, this is when examining the crash log can be useful, and could help solve the problem.

Common causes include:

  • macOS intentionally crashed the app because of an error in code signing, or another serious security failure;
  • the app failed because it was in translocation;
  • the app couldn’t open a damaged or incompatible document;
  • the app had a problem with its Preferences.

Signs and logs

Depending on the type of Mac, the version of macOS it’s running, and the nature of the crash, you may see nothing at all, a simple notification, or a full crash report.

crashreport2

crashreport1

While panic logs can be impossible to recover if you miss them, app crash reports are almost invariably saved to disk, normally in the path ~/Library/Logs/DiagnosticReports, although in some cases you’ll have to look a bit harder there, or in /Library/Logs/DiagnosticReports. As the report’s name should start with the app name, they’re easy to identify, and double-clicking them opens the report in Console (one of its good uses).

Reading the crash log

In the upper Translated Report look for the following:

  • Path – check whether this is a long semi-random path typical of app translocation.
  • Code Type – on an Apple silicon Mac, check whether the app is running native on Arm, or translated by Rosetta 2.
  • Exception Type – this could be EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) if macOS has crashed the app because of a code signing problem.
  • Termination Reason – this may be given as Namespace CODESIGNING, Code 2 Invalid Page or similar for code signature problems.

An exception type of EXC_CRASH (SIGKILL) indicates macOS terminated the app, and its crash report should give a Termination Reason with a code explaining the reason for the crash. Apple silicon Macs running recent versions of macOS are less likely to crash apps with signature problems, as they now tend to handle these in a dialog reporting the app is damaged and offering to remove it. Intel Macs with older macOS are more likely to crash the app and leave you wondering.

If you want to learn more about crash reports, they’re well documented for developers, starting from this master page. Worth reading are:

Code signing errors

One recent and innocent cause of signing and notarisation errors occurs in apps that update themselves, normally using the popular Sparkle method. If an app had worked fine before it updated itself and then can’t start up, it may not have updated its code signature or notarisation correctly. This is easy to fix, by deleting the broken app and downloading a fresh copy of the current version. If that still crashes with a signature error, contact its developer as it may have a bigger problem.

Apparency, free from Mothers Ruin, is the definitive app for checking code signing and notarisation problems. It doesn’t just identify the problem, but explains it in careful detail.

If you’re absolutely certain that the app doesn’t contain any malicious code, you may be able to work around code signing errors by re-signing the app. Doing this to an app that might be malicious would be extremely dangerous, so you require great confidence in the app’s integrity.

Before proceeding any further, you might need to add Terminal to the list in the App Management section of Privacy & Security settings, otherwise your commands could be unable to make any changes to the app. Once you’ve done that, open Terminal and use the command
codesign --remove-signature MyApp.app
to strip the existing signature from the app MyApp.app. Note that two hyphens precede remove-signature. When that’s done, use the command
codesign --sign - MyApp.app
to sign that app with an ad hoc signature. Ad hoc signatures provide only limited security, as they don’t use an Apple-issued certificate for verification against a chain of trust. They’re widely used by malware as a result, and easily exploited.

If that doesn’t work you’ll need to refer the problem to the app’s developer, who should in any case be informed of any problems with their app’s code signature, notarisation or security checks.

App translocation

There are some circumstances in which perfectly good apps may prove unable to run as expected when they’ve been translocated, and some become stuck in translocation, continuing to crash each time you try to run them. If you’ve looked at the crash log, the Path given there should make it obvious if that app is being run in translocation.

The best solution is to try reinstalling the app. Delete the current copy, and download the app again from its source on the internet. If it comes as a compressed archive, decompress it, then move the app from the folder it came in to one of your Applications folders before trying to run it. Do this one app at a time, rather than as one of several, and ensure it doesn’t remain in the folder it came in. If that doesn’t help, contact its developer.

A more hazardous option is to strip the quarantine extended attribute from the download, but you should only consider that as a last resort as it reduces the security checks made by macOS.

Failed to open document

If the app was last quit with a document still open, and that document now has a serious incompatibility with the app, that can cause the app to crash when it’s next opened, and tries to re-open that document. The same effect can occur when an app is opened by opening one of its documents. Try opening the app alone before opening the document. If necessary you can enable Close windows when quitting an application, in the Windows section of Desktop & Dock settings, or move the offending document to a different volume so that app loses track of it.

Preference file problems

Apps that use Property List files stored in ~/Library/Preferences, or an equivalent in the app’s folder in the ~/Library/Containers folder, open them during app startup. If that preference file is malformed or corrupted, it can cause the app to crash when it tries reading it. This may not be easy to recognise in a crash log, although references there to cfprefsd, the path to the preference file, or UserDefaults are useful clues.

The best way to address this is to delete the app’s preference file, forcing the app to create a fresh default preference file, and open normally again. Although you can do this by locating the correct file and dragging it to the Trash, it’s more reliable to use the defaults command in Terminal, as that should delete the right copy and avoid overwriting it and causing the problem to recur. For this you’ll need the app’s formal ID, available from Apparency or taking a peek at the value for the CFBundleIdentifier key in its Info.plist. It should be in the form of a reverse URL like com.mothersruin.Apparency.

The command that you need to enter into Terminal is of the form
defaults delete com.developer.appname
where com.developer.appname is the app’s ID or CFBundleIdentifier.

You should then be able to open the app, which will have to recreate its default settings, hopefully without crashing again.

Other causes

Most other potential causes tend to prolong app opening rather than causing it to crash. Apps that check for updates over the internet usually do so soon after opening, but should perform that check without blocking or crashing the app. Similarly, apps needing to connect to an external authorisation service more usually hang, leaving their Dock icon bouncing indefinitely.

Any damaged or incompatible app may well crash during opening. If you suspect that, check with the app’s support site that the version you are trying to run is the latest that’s compatible with your Mac and macOS. If in doubt, re-install the app.

似乎也不曾有过选择

雨天在舞蹈室边上等儿子下课,写点东西吧。

其实一直以来我对于「自媒体」这件事的态度是:这不是我的副业或者支线,它甚至不是一件事情或者工作,而是一个基础配置。

我是从98/99年前后开始在网上的论坛里写东西的,那会还是初中生,到2005年上了大学,正好遇到了博客那股潮流,就做了自己的博客。直到今天,博客依然是我真正意义上的主阵地,而不是哪个社交媒体平台。平台上的「你」,始终是被规训在算法下的素材,所以对于我而言,那些地方是把我零散分发的渠道。我认为这是我的平台帐号一直做不大的核心原因:我从不相信那套叙事框架,发自内心地不在乎。

但为什么这么些年还一直在发内容呢?因为我的动机和正反馈不来自读者观众听众,而是我就是停不下来要琢磨这些事情,并且我一定要把这些事情整理好弄出来。内容放在哪里都可以,它只是一个保存的形式。因此我认同李如一的一句糙话:创作是创作者的排泄物。是的,我做内容只是因为我不排泄出来不舒服,我无法停下来。

但,这并不意味着我需要或渴望传播。传播是一件不可控的事情,它不会影响我要或不要做某个东西的判断。

作为一个工业设计师,自媒体账号是一种保持在线状态的方式。这更像是在观察社会。知乎12w、B站4.6w、微博4.4w,这几乎已经是我这些枯燥内容自然边界的极限了。朋友问我你还继续做下去吗?对我来说这不构成一个问题,因为我做内容是纯自发的,有没有钱我都做,做了就想发出来,发出来只是纯分享,除此以外都随缘。

我知道这没有商业价值,但我似乎也不在意在这个领域里有没有商业价值。尽管有些客户指定要我,但我很清楚他们对我的需求,在整个市场里是小到几乎可以忽略的。尤其今天这种环境下,长尾内容更像是一种非必要的累赘。

我真正在乎的设计创作,却总在碰壁。没办法,双拳难敌各怀鬼胎。毕竟工业设计的前缀是工业,链条上的人不行,那就不行,再想做好也是徒劳,哪怕你的手已经向前后端都伸了出去。但要说就这么放弃么?也不行,或者说,你还总能看到各种星星点点的希望。

然后结果就是,设计那边你对什么都不满意,而内容那边你又无法令大家满意。

也许接下来的几个月,我得做出选择。但可能其实没有选择,那我会被引导去哪条路上呢?

下一个英伟达?苹果的 AI 布局可能藏在 iPhone Air 里|设以观复 vol.18

前段时间,一款改装的「透明版 iPhone Air」在网上引起了热议 。

但是,直接剥离背板油漆露出内部精密零件,真的是一种很酷的极客审美,还是对工业设计的一种糟糕误解 ?本期节目,我们将穿过这场透明风波,去扒一扒 iPhone Air 玻璃背板下真正隐藏的极端工程追求 。同时,我们也将借此一窥,在 AI 开始接管物理世界的今天,科技巨头们到底在暗中筹划着一个怎样的未来 ?

🎥 点击图片播放视频

在 YouTube 观看视频:https://youtu.be/tIDCztqm9I8

在 Bilibili 观看视频:https://suithink.me/2026/04/01/16ylog/

本期主要议题

把精密零件裸露出来就是很酷的设计感吗 ?我们将重新审视历史上经典透明设计的真正语境,聊聊为什么「透明版 iPhone Air」本质上可能是一场审美误会 。

iPhone Air 让人惊叹的纤薄,并不仅仅是视觉和比例上的魔法,更源于对核心元器件集成度边界的疯狂压榨 。苹果全新的“高原”设计语言和 Apple Watch 有什么关联 ?

标准版 iPhone 面向当下,而 Air 却是一个指向未来的坐标 。当计算核心不再被强制绑定在一块大屏幕之下,我们身边的电子设备生态将迎来怎样的一场无声大洗牌 

AI 的颠覆绝不止于聊天、写代码或生成图片,它正在悄悄渗透进物理世界的技术栈里 。结合苹果近期低调收购的 AI 初创公司,以及 Air 机身上隐藏的全球最大消费级 3D 打印零件,AI 驱动的逆向工程将如何改变我们习以为常的几何美学 ?

作为极具前瞻性的工程探索,iPhone Air 遭遇了商业上的滑铁卢 。既然时机并未成熟,消费者也倾向于“既要又要”,为什么 Apple 仍然愿意掏出这笔极其昂贵的「学费」 ?

👇本期关联播客

https://suithink.me/2026/04/01/16ylog/

补充一个AI逆向设计的工程案例:

https://weibo.com/1401527553/5282872370135897

为什么说商业失利的 iPhone Air,藏着苹果 AI 进入物理世界的路径_16.ylog

节目简介

欢迎收听这期节目!前段时间,一款改装的「透明版 iPhone Air」在网上引起了热议 。但是,直接剥离背板油漆露出内部精密零件,真的是一种很酷的极客审美,还是对工业设计的一种糟糕误解 ?本期节目,我们将穿过这场透明风波,去扒一扒 iPhone Air 玻璃背板下真正隐藏的极端工程追求 。同时,我们也将借此一窥,在 AI 开始接管物理世界的今天,科技巨头们到底在暗中筹划着一个怎样的未来 ?

Show Notes

把精密零件裸露出来就是很酷的设计感吗 ?我们将重新审视历史上经典透明设计的真正语境,聊聊为什么「透明版 iPhone Air」本质上可能是一场审美误会 。

iPhone Air 让人惊叹的纤薄,并不仅仅是视觉和比例上的魔法,更源于对核心元器件集成度边界的疯狂压榨 。苹果全新的“高原”设计语言和 Apple Watch 有什么关联 ?

标准版 iPhone 面向当下,而 Air 却是一个指向未来的坐标 。当计算核心不再被强制绑定在一块大屏幕之下,我们身边的电子设备生态将迎来怎样的一场无声大洗牌 

AI 的颠覆绝不止于聊天、写代码或生成图片,它正在悄悄渗透进物理世界的技术栈里 。结合苹果近期低调收购的 AI 初创公司,以及 Air 机身上隐藏的全球最大消费级 3D 打印零件,AI 驱动的逆向工程将如何改变我们习以为常的几何美学 ?

作为极具前瞻性的工程探索,iPhone Air 遭遇了商业上的滑铁卢 。既然时机并未成熟,消费者也倾向于“既要又要”,为什么 Apple 仍然愿意掏出这笔极其昂贵的「学费」 ?

👇 本期互动问题:

如果未来的计算设备真的变成了一张看不见、摸不着的分布式网络,手机这个实体彻底消失,你觉得人类最难克服的「物理习惯」会是什么呢?欢迎在评论区留言,跟我们一起大开脑洞!

🎥本期关联视频

https://www.bilibili.com/video/BV1Qw9jBeESW/

|相关链接|

若你所使用的播客客户端未能完整显示插图,或遇网络问题未能正常播放,请访问:

荒野楼阁 WildloG 的地址:https://suithink.me/zlink/podcast/

阅读设计相关的各类文章:https://suithink.me/zlink/idea/

|其他社交网络媒体|

苏志斌 @ 知乎|SUiTHiNK @ 即刻 / 微博

苏志斌SUiTHiNK @ Bilibili / YouTube / 小红书

|联络邮箱|

suithink.su@gmail.com

欢迎在 小宇宙、Spotify、YouTube、Apple Podcast 收听本节目,期待你的留言。

💾

六个字:蓬荜生辉!

前年(或去年?)在网上见到 More Tong 的这组《乘物·游心》时,就特别想入手,但刚找到小店就看见售罄了。今年新做的这组《宇·宙》更有意思,两字抱揽之内皆是我的宇宙。眼见着「库存仅余1件」,一边念着「怎么网速那么快」一边直接下单。缓了口气后,发现旧作竟然复刻了!这都是运气!

我这个小空间里没什么艺术气息,更多是个工具间和库房,因此疏于妆扮。但 More 这四张海报一进场,配合纤细冷峻的铝制画框,小破屋竟有那么几分像是个艺术画廊。

自制一对小鱼符 :)

看完《太平年》后,相上了这枚小九单挑萧山大营的鱼符,于是果断手搓了一对!

小时候也好奇过这虎符、龟符、鱼符是怎么用的,为什么可以调兵遣将?直到前些年才知道它的工作原理:首先符的轮廓不统一,各军各地对应不同的款式和造型,然后内侧用阴文阳文刻有「同」字,携带者与调遣者双方拿出来,能合上且轮廓一致就算对上密码了。虎符龟符亦然,只是各朝各代形制不同而已。

剧里的鱼符柴瘦柴瘦的,博物馆里的实物也是以瘦鱼居多,难得喝口太平年下的热酒,那就还是做一条小胖鱼吧:)

金色鱼是香槟金,料本身有点哑光,所以层纹没那么明显;银色鱼是丝绸银,也许是料放久了有点受潮,所以才那么吱吱啦啦的。这是第一版,各位路过的乡亲豪杰给点建议呗?

趣味即偏离

小时候,我很喜欢包书皮。因为是用旧日历,把空白的那一面朝外,我可以任自己喜欢地在封面上画各式各样的东西,也可以把科目的标题画得五花八门,就连自己的名字、班级、学号也不放过。总之,整个封面的每一处细节,都是我自己画的。书皮,就是我的作品。

甚至于,学期中还能重新包,重新设计。

如今的包书皮,是一个产业,是标准,是流程,是例行公事地把印刷清晰的亮面,包成雾蒙蒙的哑面。甚至有些课本,预留出了包书皮的空间,把学生信息设计在了靠内侧恰好避开的位置。

儿子问我:“爸爸,这个设计好吗?”
我说好啊,这是很棒的引导!

但有一点可惜,趣味和想象力也随之消失了。

可这并不是设计的问题,也不是产业的问题。过去的人用旧日历、旧报纸、旧海报包书皮,虽然五花八门,但也百花齐放。我有个发小,他爸给他包的书皮,是铁片做的,四个角都是角铁,若砸头上,那是真能开瓢的。但总有包不好、做不来的,不在少数。

工业化、产业化是解决了痛点的。只是,任何事情一旦把门槛放到了「任何人都可以轻易执行」的程度,人就不再是个体了,大家只是集体、算法、架构里的一粒沙子、一个变量、一颗齿轮。

很多人以为 AI 会释放人们的创造力,迎来空前繁荣。

不,创作行为不会因为工具、媒介、传播渠道而改变其本质,它总是关于「偏离标准值」的。标准的书皮贴再多,也做不出一张像样的封面。创作是关于累积了多少心力的,「方便」降低了生产平庸的门槛,但绝不会降低「认真」的门槛。

趣味就在粗砺的偏离之中。

最后一次更新这款眼镜框了!

终于改舒服了!也是最后一次折腾了!

一来是这一版的尺度、重量分布、松紧程度都达到了目前为止最舒服的状态;二来,从二月折腾到现在,拆装无数回,原本的镜框已经散架得没法拼了,镜片外围也都花得不行,经不起下一轮折腾了。

谁家的AR眼镜要是在佩戴舒适性、风骚程度达不到我设计这款的水平,那我就还是继续戴传统眼镜吧。你们加油!

[设计思维] 2 clicks x7 per week

简单分享一款个人使用的药盒的设计思路和细节。

不深刻,没巧思,就是图一乐。

🎥 BiliBili:https://www.bilibili.com/video/BV1c5BiBPE8o/

🎥 YouTube:https://youtu.be/YjmS7CaiwHo

我并不是因为「这个设计特好」所以要分享,而是「就是想分享一下」这样的心情。但这不妨碍我在拍摄和剪辑中倾注的心思,镜头的衔接与节奏的控制,这种事情我做得还蛮开心的。

最近都没有忘记吃药了!

【开源】告别臃肿和散乱|日历支架设计方案

这是一款为砖型日历设计的支架。

旨在用更小的体积和占地面积,完成摆放、收纳整理。

这是一个为我个人需求设计的模型,如果你有更好的想法,欢迎改良它!

🟢 模型及打印配置文件在这里:https://makerworld.com.cn/zh/models/1903991

🔵 设计讲解的视频看这里:https://www.bilibili.com/video/BV1XLqgBkESW/

另外再说一些没在视频里分享的技术细节吧,因为我觉得这些细节直接看图文会比视频更合适、更高效。

主体零件底座那一块的料厚我设置了 5 层,也就是 2 mm 厚;但上面围墙的部分,我只设置了 2 层墙。一方面是为了把重心下移,底部的密度要大于上半截;另一方面也通过更厚的墙减少了大量填充。

不同的墙厚 + 降低填充,让整体消耗量从 230+g 下降到 125g,也保证了强度和重心。

然后,我通过添加修改器,加强了后端凸出的结构特征的填充密度。

一者,强化受力部分的强度;二者,进一步把重心拉向下后侧。

但这里我特意把修改器往上挪了一点,避免出现从底部开始和主体部分墙分开的情况。从切片里可以看到,最底部的基层是一整块连在一起的完整结构,往上几层才开始有密度上的变化。

再有一处细节是,尾部的撑脚其实本来可以和主体做一体的,但我为了能在色彩上玩一些小心思,就拆了一件。拆出来的这一件和主体之间,是采用凸点和凹坑来过盈配合去固定的。

这一处的小心思在于,我没有用两侧对称的方式来做,而是左边的凸点全部朝右,右边的凸点全部朝左。这样装上去之后,两边会形成互相对抗的力,完全顶死没用松动,很牢固。

好吧!最后祝你打印愉快 😛

宝可梦的地图里,隐藏着创作的宝珠

最近我重新开始玩宝可梦系列作品《走吧!皮卡丘》,玩着玩着发现了一个小彩蛋:在玉虹市的玉虹大厦三楼走廊尽头,有个专门为「游戏狂想家」这家公司安排的小空间。

我当时就想:

“哇,这家游戏工作室专门埋了一个独属于自己的小彩蛋?任天堂没有意见吗?他们俩背后到底有什么故事呢?”

我一开始查资料,就停不下来了 —— Game Freak(游戏狂想家)、HAL、任天堂、宝可梦 IP,这些名字背后的历史和关系,远比我以为的要复杂得多。与此同时我还发现,这其实是一个很生动的案例,告诉我们,创意如何在制度化、战略化的环境下持续落地。这套逻辑对做品牌和设计咨询,也特别有启发。


任天堂、Game Freak 和宝可梦的故事

先从 Game Freak 说起。很多人以为宝可梦一出世就是大团队作品,其实它的起源很有意思:

  • 1983 年:田尻智和杉森建创办了《Game Freak》同人杂志,全手工装订,大家都是为了分享创意和玩法。
  • 1987 年:他们受南梦宫委托开发了《Mario Bros. Special》的 PC 版,这是第一次尝试电子游戏的商业开发。
  • 1989 年 4 月 26 日:Game Freak 正式注册公司,从同人杂志团队变成了专业的游戏开发商[1]。

看到这,你可能会想:“哇,他们是从杂志直接跳到宝可梦吗?”其实不是,他们先做了几款外包软件,尝到商业开发的甜头后才真正走上这条路。这个过程告诉我们:独立创意很重要,但商业化和持续发展,需要制度和经验的积累。

接着是宝可梦的版权问题,很多人理解错了。宝可梦可不是任天堂的独家 IP,它的结构是这样的:

  • Game Freak:程序和主要设计
  • Creatures Inc.:角色模型和素材
  • The Pokémon Company(TPC):任天堂与前两家一起,三方共同成立的公司,统一管理品牌、商标、授权和收益,三方股权各占大约三分之一[2]

所以任天堂虽然不是唯一版权方,但它独占主机平台的全球发行权,并持 TPC 股份约三分之一。手游、卡牌之类的授权则由 TPC 直接处理。换句话说,版权和发行权分开、责任和利益明确,创意团队既有自由又有制度支撑,这也是宝可梦能长期保持高质量的关键。

相似的案例,我们再来说说《星之卡比》的主要开发团队,HAL 研究所。1992 年,他们负债约 15 亿日元,任天堂没有直接收购,而是通过追加订单、提前支付版税和信用担保来帮他们渡过难关[3][4]。

1993 年,临危受命的岩田聪出任 HAL 社长,他做了几个关键动作:

  • 半年内裁掉三分之一团队
  • 取消六个高风险项目
  • 集中资源开发《星之卡比 2》

结果,1995 年游戏销量突破 100 万套,公司成功扭亏[4][5]。星之卡比的版权归任天堂,但 HAL 保留开发署名权(© Nintendo / HAL Laboratory)[5]。2000 年,岩田聪入职任天堂,两年后出任社长,任天堂与 HAL 的关系更进一步。

整个逻辑很清楚:制度化支持 + 资源集中 = 危机管理成功。任天堂既保证了关键 IP 安全,又保留了 HAL 的创新能力。

顺便说一下任天堂的独家 IP 案例,你可以看到规律:

  • 马力欧(Nintendo EPD)
  • 塞尔达传说(Nintendo EPD)
  • 星之卡比(HAL 开发,IP 属任天堂)
  • 火焰之纹章(Intelligent Systems 主开发)
  • 银河战士 Metroid(Retro Studios / Nintendo EPD)
  • 喷射战士 Splatoon(Nintendo EPD)

规律是:开发分散,版权集中,生态稳固。换句话说,创意团队有空间,战略和商业被制度化保障。这一点对品牌和设计咨询来说特别值得学习。


从任天堂逻辑到品牌与设计咨询的启发

知道了这些,你可能会问:那和我们的品牌/设计咨询有什么关系?其实你看,任天堂的做法和庞大的 IP 收益已经明确告诉了我们,想要长久高效地产出创意,必须有清晰规则 + 制度化支持 + 战略长期稳定

这里有几个关键点:

1. 长期战略伙伴

  • 不是只做一次性的设计方案,而是提供长期的战略判断
  • 输出的价值不仅是结果,还有流程、框架和定期校准
  • 高价值在于长期陪伴和战略能力
  • 弹性的框架给创意滋生提供优秀的孵化土壤

2. 品牌“主机”:核心规则与创新空间

  • 核心规则:品牌价值观、核心叙事、设计原则
  • 创意空间:让团队自由发挥
  • 核心统一 + 创意弹性 = 长期可持续

就像宝可梦里,开发团队可以自由设计游戏机制、精灵、玩法创新,但发行和品牌逻辑有统一的规则,保证整个生态长期稳定。

3. 制度化校准

  • 可每个月以安排一次深度品牌校准会
  • 明确主线,输出决策方法,让战略落地
  • 咨询方成为长期的战略伙伴

这样可以保证方向不跑偏,创意不散乱,也让各个团队知道自己在做什么。

4. 启示的核心

简单来说,如果我们把任天堂三方合作、版权集中、创意独立的逻辑搬到品牌/设计咨询里。核心就应该是:

  • 规则要清楚
  • 执行有弹性
  • 战略长期稳定

实践大概分四步:

  1. 事实梳理:先把过去的成功和失败、团队和市场的价值认同梳理清楚
  2. 品牌主机搭建:核心叙事、设计原则、决策框架
  3. 制度化校准:每月一次深度复盘
  4. 总结价值:方向清楚、决策高效、创意可持续、团队活力长久

最后总结一下,我自己体会最深的四点:

  • 权责明确:谁做什么、谁负责什么,一目了然
  • 核心统一 + 执行弹性:核心稳定,创意自由
  • 制度化合作:定期校准,长期稳定
  • 长期伙伴观:咨询方不仅是执行者,更是战略伙伴

如果你的品牌希望在快速变化的市场里保持方向清晰、创意可持续、执行高效,这套逻辑很值得参考。

我是从业 16 年的工业设计师苏志斌,乙方甲方都有相当从足的从业体会:服务过的客户中,既有创客类型的初创小团队,也有世界 500 强的领军企业;设计落地的产品中既有成熟行业的精准创新,也有新领域新品类的挖掘和探索。

如果你的团队需要 产品创新/工业设计/品牌策略 等帮助,可以私信或邮件联系我:

suithink.su@gmail.com

我更多关于产品/设计/企业的思考和见解,欢迎在这里收看我的节目:


📌 尾注

  1. 《ゲームフリーク 設立記念インタビュー》4Gamer,2016-02-26
  2. TPC 第 7 期有价证券报告书(2023-05-31)
  3. 《岩田聪传》日经 BP,2010,pp.68-71
  4. 《週刊朝日》1996-03-08 采访
  5. 日本版权登记数据库:1018608601「星のカービィ」
  6. 本文由 ChatGPT、Kimi、DeepSeek 协助完成

小柒的第一次摆摊:+13 -2

这一周给儿子打印了一批宝可梦,给他在今天下午学校组织的跳蚤市场中售卖。一共四个款式,分别是皮卡丘、妙蛙种子、杰尼龟和小火龙,每一款 5 个,共 20 个。单个的成本大约在 1.5~2 元之间,他的计划定价是每个 5 元,所以如果全部销售完,预期利润大概是 60~70 之间。

回来之后,他拿出所有钱给我看,一共 76 元。我一共给了他 78 元。净利润 -2 元。

于是我们完整复盘了一遍:

1、实际销售中,同学们都把价格砍到 2~3 元成交,只有他的好朋友和语文老师以他的计划定价来购买。其中,语文老师买了两个,其中一个小火龙因为尾巴上的火团断裂导致折价销售。这里一笔 5 元,一笔 8 元。因此,他实际的平均成交价大概在 3 元上下。

2、有许多同学来他的摊位上,把自己的东西卖给他。名义上,他们是说把东西给他来「换取」现金,用于购买商品。有人在他这里买了宝可梦,有人则是拿到钱后去别处购买。于是事实上形成了一个结果,那就是他被别人以「兑换现金」的名义,平白无故地买了大量他不需要的东西。

3、在他购入这些货品后,也有许多同学从他这里买走了这些货品。但是问题在于,他还是按照收购的价格来报价,于是在对方进一步砍价之后,实际上出现了他高买低卖的情况。

4、尽管最终他卖光了所有货品,无论是我们自己准备的这 20 个宝可梦,还是别人来他这里「置换」的货品,但最终他的成本攀升到了大约 8 元上下。这是影响他利润的最主要原因。

5、在活动现场,他自己主观意愿购买的两件商品,一个龙虾的毛绒玩具,10 元,一个摩托车玩具,5 元,一共支出了 15 元用于消费。

于是,我们算出来的结果是,他的净利润是 13 元,因为消费了 15 元,导致最后的盈余是 -2 元。

一开始他说自己赚了不少,但我看出来他是知道自己亏了,只是不愿意面对。随着我带着他一点一点回忆和整理,我确认了几件事:

1、没有人趁他不注意拿走东西,所有交易都是在他眼下实际发生的,来往的货品和现金都是真实发生的。

2、跟他合伙的同学从一开始就用低价策略来吸引客群,导致来他摊位上的人天然地认为可以在他的定价下继续压价。尽管他不断指出对方不应该这样叫卖,但现场的局势已经不可控,他担心不降价就无法促成交易,于是只好降价销售。

3、他确实没有记账,所以实际上的成交价和数量他都只有大概的印象,别人「兑换」给他的价格和数量也没有清晰的数据。大致的价格和数量,是我们通过预期利润和实际利润的差额倒推出来的大概的范围。

其实我一开始就没预期他能在活动上赚钱,所以数出来最终盈余是 76 时,我还觉得「蛮不错的」嘛。毕竟这是第一次真枪实弹地接触商业,我小时候可完全没有这种机会,更没有人来教我怎么做这件事。数学归数学,交易是交易,亲自体验一次本就是好的。

我跟他说,最大的问题出在别人来找你「兑换」的时候。

第一,你其实没有义务配合他。他没有现金,是他的事,不是你的事,你是卖家。即便你要收购,也可以跟对方讲价,按低价收购,再喊高价卖出。因为别人来你的摊位上都可以砍价,那当别人要卖东西给你的时候,你砍价也是很合理的,你没义务去配合他。

第二,降价销售可以,无非是利润少一点。你既然知道成本是 1.5~2 元,所以不会低于 2 元销售,那其实也可以知道,从别人那里进货也应该低进高出。你可以留点余量给对方讨价还价,但只要咬住成本,至少咱们不会亏。

小柒挺聪明的,心里清楚这次没搞好。

一开始他还有点回避,生怕我责备他。后来听我仔仔细细地询问每一个环节,确认交易是否公平合理,一笔一笔账地算,利润的缺口从哪里来,怎么样可以避免,他也还是逐渐听进去了,主动给我说当时的一些细节。

不管怎样,作为第一次,小亏就是赚。经验和体验,是最重要的。

同时,这次实践也得到了一个明确的信息:皮卡丘和妙蛙种子的人气远超杰尼龟和小火龙,那俩一下子就售空了!这个颜值经济啊,任何时候都足够强势呐!

风格只是幻觉

风格是品牌的故事,是创作的来时路,但不是我们追求的样子。它只是一系列机缘巧合下的幻觉。

好啦~大师之钥这回真上线了!

前段时间陆续在 🍠 后台私信出了三把 😂 这是万万没想到的…… 鉴于各个平台一直都有人问我有没有购买链接,那就索性上架水产市场,就当赛博摆摊了。

当然,以摆为主,随缘出。

🌼 温馨提示:
这是拧架子鼓螺母用的鼓钥匙,如果你既不打鼓也不玩塞尔达,就没必要看了哈。不过,它有挂孔,当个项链或者包包挂饰也还是 OK 的。

就酱紫吧 🙂

大师之钥补完计划 :||

在 2.0 版本的基础上增加了剑尖的胶塞,形态上组成了一把完整的大师之剑。

当它没有作为鼓钥匙来使用的情况下,可以作为项链或者包包的挂饰来使用。

光之舞:ムーンライト伝説(月光傳說)

在网上看到一条类似的视频,就自己建模打印,复刻了一下:

然后呢,为了录制这条视频,特意去楼下便利店雇了一位打火机演员。但店里没有别的款式,我又嫌他出镜不好看,就打印了一件外套给他穿上,再画了个老钱妆容。

这下谁还知道他是跑龙套的?

虽然正片里他没什么露脸的镜头,但逆光的侧颜也是还可以的 🙂

大师之钥 2.0 全新版本!

很早就想改良了,但是一直懒得做结构。自从上次给小红书网友定制了小樱和皮卡丘的鼓钥匙,终于对改良大师之钥有了具体的思路。这两天趁着设计项目进度慢下来,就赶紧测试了三四个版本,终于确定下来了!

相比二月份做的版本,2.0 有更好的外观 + 更强的结构:

1、从一体打印改为分件设计;
2、提升关键结构的强度和耐久;
3、更接近原作的配色与质感;
4、可量产的打印配置;
5、可拓展/定制的设计架构。

我真是无所不能啊 :p hiahiahia~

相比初代,可以说是质的飞跃了!

当然,2.0 也可以有丝光版本。

在同一种材质下对比,就更能看出不同的工艺和拆件设计,对成品质量的影响有多大了。虽然会增加两条拆件线,但所有外观面的品质都提升了相当多。

通体丝光,咋一看是非常讨好眼球的,但就像美颜过度的照片,既会显得成品油,又会导致视觉失重没有焦点。剑柄没有抢宝石和剑身的戏,这个节奏更恰当一些。不过,具体的颜色和材料,未来还可以再继续试。

二月做初版的时候,还没尝试过什么其他材料,这种图新鲜和拿锤子找钉子的心情,和二十年前刚认识设计的时候很像:

堆料就是好!More is gooooood!

这个过程或许真的很难完全省略或者跳过,但可以随着自我成长,缩短每一次进入的时间和路程。

3I/ATLAS_SUiTHiNKModel_v1

那年冬天,国际天文学联合观测网宣布,人类再次捕捉到一个“跨恒星访客”。
代号:3I / ATLAS

它并非金属,也不像冰体。所有望远镜的数据都在闪烁、紊乱、跳跃。
有科学家提出,它的表面并非反光均匀,而是一种会散射观测波段的天然迷彩。
这意味着,它在主动隐藏自己。

天文学家称之为“被注视的凝视物”。


一、模型

两个月后,一个名叫苏弋的工业设计师在社交媒体上发布了一张照片。
他掌心托着一个13厘米长的灰黑色小模型,表面布满刻意的不规则反光。
标题很简单:

3I/ATLAS_SUiTHiNKModel_v1

照片下没有说明,也没有解释。
但第二天早晨,它就出现在各大科技博主与艺术账号的页面上。
短短几天,#ATLAS掌心体# 的话题播放量突破一千万。

人们惊讶地发现:这个模型拿在手里,会因角度与光线不同而不断改变亮度与轮廓,好像真的在呼吸。
没有任何机械结构,却让人产生一种“被凝视”的幻觉。

潮流品牌纷纷推出联名款、限量款,甚至高定银质版本。
3I/ATLAS 成了地球上最受欢迎的“掌心饰物”。


二、名字

直到那时,人们才开始注意到模型命名里那个奇怪的后缀:SUiTHiNK

起初只是粉丝在 Reddit 上随口猜测:

“是不是苏弋 think 的意思?他在表达‘思考的我’?”

很快,语言学与符号学圈子加入了讨论。
牛津大学的一位古文字学家在论坛上指出,SUi 在苏美尔语音节表中确有记录,对应音素「šù-i」,意为“手中之物”或“掌握的”。
而 THiNK 若取古日耳曼转写体系中「þenkaz」的变体,则可指“思想、意志”。

这两个词放在一起——SUi / THiNK——意外构成一种双重结构:

“思想被握于手中”
“手成为思想的延伸”

正好对应了那枚贴合掌心的模型。


三、文件

一个名为《ATLAS分析草稿》的PDF文件在暗网流出,署名不明。
文件记录了苏弋受邀前往某个“国际天文资料保存计划”设计储存容器的过程。
文件被加密,只能读到部分片段:

「……他拒绝使用镜面金属,要求采用能分散反射的表层……」
「……他说它看我们的方式,与光的角度有关……」

消息曝光后,网友纷纷去翻苏弋的旧贴。
有人发现,在他早期设计的数个装置艺术中,常出现一种奇怪的结构:
不规则的反光面、内部空洞、可置于掌心的尺寸。
似乎他早在3I/ATLAS出现前,就在“模拟它”。


四、失踪与重现

半年后,苏弋停止更新。
没有告别,也没有声明。
他最后一条动态是一张模糊的近景:
灰色反光面,指纹模糊,背景是实验室的冷光。

账号沉寂,模型销量却持续飙升。
ATLAS 成了新世代的“图腾物”——有人把它挂在胸前祈祷,有人说握着它冥想能听见低频嗡鸣。
心理学家解释那是“自我投射效应”,
可越来越多的视频声称,模型在暗处能“微微震动”。


五、抄本与注释

一位梵文与苏美尔语双修的学者在学术会议上展示了一页《纳格·哈玛第文库》的边注。
那是一段13世纪的修订版手抄本,边缘用拉丁混写体标注着一个模糊的词组:

“SUI · THINC”

他解释说,古修士在这里用“sui”(自我)与“thinc”(思想、议会)并置,
象征“自我与思想的合一”。
而这页手稿讨论的主题正是——“被造物如何回望造物主”

学者最后说:

“这并非巧合。有人在重新复写那一页。”


六、光的陷阱

几个月后,一个匿名账户上传了一段短片。
画面是普通实验室,一枚3I/ATLAS模型被置于光谱仪下。
随着仪器启动,反射光像是被吸入某种结构中——
在高倍放大镜头下,模型表面出现了极细的刻痕,
排列成一种自相似的螺旋分布

字幕写着:

「不是反射,而是记忆。」

短片很快被删除,但无数人下载、转发。
有科技频道尝试复刻实验,结果不同——有的只是普通塑料折射,有的却出现微光闪烁。

人们开始相信,真正的那批限量模型里藏着“某种东西”。


七、余波

如今,3I/ATLAS 已成全球设计学院的研究对象。
有人研究其造型心理学,有人分析其符号学层次。
但没人再提那个名字——苏弋

只有极少数人记得,他在一篇采访中留下过一句话:

“如果我们注视的东西,也在注视我们,那我们看到的,或许只是它让我们看到的部分。”

这句话如今被无数次印在ATLAS周边的包装盒上,
也被误以为是广告语。

而在某个收藏论坛上,一张从未公开的照片被匿名发出:
桌上放着数枚模型,灯光昏暗,镜头对焦在最后一排。
那些模型的反光形成一条微弱的线,连成一个英文单词——

RETURN.

模型由我使用 Midjourney、Tripo 设计制作;

短文由 ChatGPT 配合我完成;

首图为模型实拍,经 Banana 和 Snapseed 处理。

点击这里打印模型,祝大家玩得开心!

水瓶提手 17g 30min 模型分享

这是我在 MW 社区分享的第二个模型。

起因是,我几乎每天都要从家里提一瓶纯净水到工作室,但原装提手经常断裂,于是我想自己做一款舒服的提手。在没有依靠社区内的已有模型的情况下,我自己用卡尺测量尺寸,制图、测试、反复修改,终于做出了一版自己比较满意的提手。

这款提手主要有以下几个设计点:

1、完全基于平面化打印的设计,打印成功率非常高;

2、提手部分宽大厚实,不勒手;

3、双肩带设计,既确保携带时的重心平稳,也提高了破损容错率;

4、出色的柔韧性。

点击这里播放相关介绍视频:SUTiHiNK @Bilibili SUiTHiNK @YouTube

打印建议:

1、使用 PETG 材料;

2、尽量不要修改已设置好的打印参数;

3、如果修改参数,请确保墙层数不低于 5,层高不大于 0.2 mm。

点击这里,跳转至打印配置页面!

鼓钥匙:小樱魔杖

之前给朋友做过一款赛尔达大师之剑的鼓钥匙,发出来以后陆续收到不少私信问能不能定制其他款式。

说实话,鼓钥匙这个形态它还是限制比较多的。因为要跟架子鼓本身的结构配合,所以很多造型没有办法做。

这一把小樱的钥匙,磨磨蹭蹭也做了将近三个月。当然,并不是说做这把钥匙需要花那么长时间,只是因为我是用身体状态正常的间隙时间,抽空一点一点弄的。当中也测试验证了很多轮不同的结构、拆件和打印方式,最终才找到了一个比较合适的方案。回头我再整理一下过程,发出来给大家看看。

我有 AMS 也不是说不能一体打印,但一体打印的话,由于打印本身的工艺限制,在 Z 轴的方向是比较脆弱的,所以在拧的时候稍不注意就会拧断。因此在设计结构的时候也尝试了蛮多种思路,最后这一版算是把结构强度跟外观质感平衡得还算满意的了。

这次尝试用 nano banana 做了两张效果图,就是粉红沙滩那两张。其实很简单,就是先拍摄实物的定妆照,再放进去修改背景和光线。效果确实相当好,省了不少事!

着眼于事情

前些天在一条小红书笔记下的留言,莫名被狂点赞。那么就备份一下吧:

38,经历了完整的十年公司生与死,目前自营工作室,不谈建议,只是一点心得分享:

分清楚他者的需求和自己的需求,明确自己长远的愿景是什么,一切过程和方法都是可以变化的,不要执著于一时半刻的得失,别人的建议和批评都不重要,知道自己要去哪里,然后分解步骤去做,遇到困难就想办法绕过去,不要浪费时间精力消耗自己,只要不停下来,就不用怕。祝好!

设计不是行业,是能力。着眼于事情,不要管什么行业不行业的。

被时间拉长的人

丢了一批人物标签给 AI 写人物小传,让它模仿某位小说家的笔法,来给演员交代角色。

你觉得这像谁的手笔?

————

南方的空气里常常有潮湿的味道,像是雨下过以后残留的影子,久久不散。城市白天拥挤喧嚣,夜晚却显得空旷,好像光亮突然被抽走,留下无数未完的句子。在这样的环境里,一个男人行走。他的脚步从不急躁,像对时间有着自己的节奏感,和别人不太一样。

年少的时候,他把自己交给了工业设计。形状、光影、比例,这些东西比人群更让他安心。六年在公司,十年在创业,那些日子像一张张被翻阅过的旧画册,色彩褪去了,但线条还在。产品的生与死,像车站里人群的来去。大多数人只看见成功或失败,他却更在意其中被忽略的细节。

别人眼中的他冷静得过分,总是习惯提前几步想好方向,就像棋局上的布局。但在那层冷静的外壳下,常常闪现一些不合逻辑的柔软时刻。比如一段旋律,随便一盏灯的影子,甚至一个不经意的眼神,足以让他停下手里的笔。理性和浪漫在心里不停打架,谁也没有赢过谁。

他知道自己带着黑暗生活。抑郁的日子像一条看不见的走廊,没有尽头。他学会了靠药物维持稳定,像有人随身带着一块怀表,偶尔瞥一眼,提醒自己仍然存在。那段经历让他对痛苦格外敏感,也让他在与人相处时多了一层隐秘的温柔。他不会轻易表现出来,但在内心深处,对别人的脆弱始终心知肚明。

夜晚经常独自坐在桌前,电脑屏幕的光照在脸上,桌上散落着草图和未完成的文字。那些想法有时像城市里的霓虹一样闪烁不定,无法全部抓住。他清楚其中大部分不会被记住,就像梦醒时遗落的片段。但仍旧一遍一遍画下去,像一种执念,也像是一种呼吸。

在喧闹的城市里,他习惯保持慢半拍的步伐。人群汹涌,他的节奏却像潜水时的心跳,缓慢、克制,不慌不忙。他看似与周围保持着距离,其实心里始终怀有一种模糊的渴望——不是要成为谁,也不是要得到什么,而是想在梦与现实之间找到某种入口。梦与梦之间,总有裂缝。裂缝里偶尔透进光。

对很多人来说,他是个不好接近的人。但真正靠近以后会发现,那些冷漠与安静只是表层,像水面下覆盖着的冰。深处的水仍然温热,流动着。理性、浪漫、痛苦和温柔同时存在,没有谁能完全把它们分开。

这样的人物,像一个在现实里造梦的旅人。他的路从不喧哗,却留下清晰的痕迹。

(*正文及标题均由 AI 完成)

换个配色,换种心情

试图用一种轻松的配色,来让自己不要那么焦虑。

前两天陪小柒和小叶去运动康复的医生那里做治疗,医生听筱烨说我有抑郁症的时候,问我有没有呕吐的躯体化反应。我当时想了想,好像没有,就跟他说没有。但昨天晚上躺在床上,想起这个问题时,我忽然想起来,去年的上半年好像有那么几个月经常会觉得喉头发紧,时不时会反酸、恶心。当时没想过是抑郁症就没在意。现在想起来,还确实是。

佛性 vs 神性

测试了一下木质材料的打印效果。难怪一直说「佛靠金装」,确实光泽感对神性的刻画非常关键。

但,神性和佛性是两条不同的路,前者是方便法门,无论于造像还是做产品做设计,都是性价比很完美的方案,而后者是一条终极孤独的路。

❌